aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)AuthorFilesLines
2019-06-23RISC-V: Raise access fault exceptions on PMP violationsHesham Almatary1-3/+6
Section 3.6 in RISC-V v1.10 privilege specification states that PMP violations report "access exceptions." The current PMP implementation has a bug which wrongly reports "page exceptions" on PMP violations. This patch fixes this bug by reporting the correct PMP access exceptions trap values. Signed-off-by: Hesham Almatary <Hesham.Almatary@cl.cam.ac.uk> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-23RISC-V: Only Check PMP if MMU translation succeedsHesham Almatary1-0/+1
The current implementation unnecessarily checks for PMP even if MMU translation failed. This may trigger a wrong PMP access exception instead of a page exception. For example, the very first instruction fetched after the first satp write in S-Mode will trigger a PMP access fault instead of an instruction fetch page fault. This patch prioritises MMU exceptions over PMP exceptions and only checks for PMP if MMU translation succeeds. This patch is required for future commits that properly report PMP exception violations if PTW succeeds. Signed-off-by: Hesham Almatary <Hesham.Almatary@cl.cam.ac.uk> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-23target/riscv: Implement riscv_cpu_unassigned_accessMichael Clark3-0/+19
This patch adds support for the riscv_cpu_unassigned_access call and will raise a load or store access fault. Signed-off-by: Michael Clark <mjc@sifive.com> [Changes by AF: - Squash two patches and rewrite commit message - Set baddr to the access address ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-23target/riscv: Fix PMP range boundary address bugDayeol Lee1-1/+1
A wrong address is passed to `pmp_is_in_range` while checking if a memory access is within a PMP range. Since the ending address of the pmp range (i.e., pmp_state.addr[i].ea) is set to the last address in the range (i.e., pmp base + pmp size - 1), memory accesses containg the last address in the range will always fail. For example, assume that a PMP range is 4KB from 0x87654000 such that the last address within the range is 0x87654fff. 1-byte access to 0x87654fff should be considered to be fully inside the PMP range. However the access now fails and complains partial inclusion because pmp_is_in_range(env, i, addr + size) returns 0 whereas pmp_is_in_range(env, i, addr) returns 1. Signed-off-by: Dayeol Lee <dayeol@berkeley.edu> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-23target/riscv: Allow setting ISA extensions via CPU propsAlistair Francis2-2/+79
This patch allows us to enable/disable the RISC-V ISA extensions from the QEMU command line. This works with the rv32 and rv64 machines. The idea is that in the future we can now add extensions and leave them disabled by default until enabled by the user. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-21Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' ↵Peter Maydell2-190/+403
into staging MIPS queue for June 21st, 2019 # gpg: Signature made Fri 21 Jun 2019 10:46:57 BST # gpg: using RSA key D4972A8967F75A65 # gpg: Good signature from "Aleksandar Markovic <amarkovic@wavecomp.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65 * remotes/amarkovic/tags/mips-queue-jun-21-2019: target/mips: Fix emulation of ILVR.<B|H|W> on big endian host target/mips: Fix emulation of ILVL.<B|H|W> on big endian host target/mips: Fix emulation of ILVOD.<B|H|W> on big endian host target/mips: Fix emulation of ILVEV.<B|H|W> on big endian host tests/tcg: target/mips: Amend tests for MSA pack instructions tests/tcg: target/mips: Include isa/ase and group name in test output target/mips: Fix if-else-switch-case arms checkpatch errors in translate.c target/mips: Fix some space checkpatch errors in translate.c MAINTAINERS: Consolidate MIPS disassembler-related items MAINTAINERS: Update file items for MIPS Malta board Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-21target/i386: kvm: Add nested migration blocker only when kernel lacks ↵Liran Alon2-3/+8
required capabilities Previous commits have added support for migration of nested virtualization workloads. This was done by utilising two new KVM capabilities: KVM_CAP_NESTED_STATE and KVM_CAP_EXCEPTION_PAYLOAD. Both which are required in order to correctly migrate such workloads. Therefore, change code to add a migration blocker for vCPUs exposed with Intel VMX or AMD SVM in case one of these kernel capabilities is missing. Signed-off-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Maran Wilson <maran.wilson@oracle.com> Message-Id: <20190619162140.133674-11-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: kvm: Add support for KVM_CAP_EXCEPTION_PAYLOADLiran Alon6-24/+187
Kernel commit c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD") introduced a new KVM capability which allows userspace to correctly distinguish between pending and injected exceptions. This distinguish is important in case of nested virtualization scenarios because a L2 pending exception can still be intercepted by the L1 hypervisor while a L2 injected exception cannot. Furthermore, when an exception is attempted to be injected by QEMU, QEMU should specify the exception payload (CR2 in case of #PF or DR6 in case of #DB) instead of having the payload already delivered in the respective vCPU register. Because in case exception is injected to L2 guest and is intercepted by L1 hypervisor, then payload needs to be reported to L1 intercept (VMExit handler) while still preserving respective vCPU register unchanged. This commit adds support for QEMU to properly utilise this new KVM capability (KVM_CAP_EXCEPTION_PAYLOAD). Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-10-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: kvm: Add support for save and restore nested stateLiran Alon3-0/+281
Kernel commit 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") introduced new IOCTLs to extract and restore vCPU state related to Intel VMX & AMD SVM. Utilize these IOCTLs to add support for migration of VMs which are running nested hypervisors. Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Maran Wilson <maran.wilson@oracle.com> Tested-by: Maran Wilson <maran.wilson@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-9-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: kvm: Block migration for vCPUs exposed with nested virtualizationLiran Alon3-13/+19
Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker") added a migration blocker for vCPU exposed with Intel VMX. However, migration should also be blocked for vCPU exposed with AMD SVM. Both cases should be blocked because QEMU should extract additional vCPU state from KVM that should be migrated as part of vCPU VMState. E.g. Whether vCPU is running in guest-mode or host-mode. Fixes: d98f26073beb ("target/i386: kvm: add VMX migration blocker") Reviewed-by: Maran Wilson <maran.wilson@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-6-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/mips: Fix emulation of ILVR.<B|H|W> on big endian hostAleksandar Markovic1-0/+37
Fix emulation of ILVR.<B|H|W> on big endian host by applying mapping of data element indexes from one endian to another. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Message-Id: <1561038349-17105-5-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/mips: Fix emulation of ILVL.<B|H|W> on big endian hostAleksandar Markovic1-0/+37
Fix emulation of ILVL.<B|H|W> on big endian host by applying mapping of data element indexes from one endian to another. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Message-Id: <1561038349-17105-4-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/mips: Fix emulation of ILVOD.<B|H|W> on big endian hostAleksandar Markovic1-0/+37
Fix emulation of ILVOD.<B|H|W> on big endian host by applying mapping of data element indexes from one endian to another. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Message-Id: <1561038349-17105-3-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/mips: Fix emulation of ILVEV.<B|H|W> on big endian hostAleksandar Markovic1-0/+37
Fix emulation of ILVEV.<B|H|W> on big endian host by applying mapping of data element indexes from one endian to another. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Message-Id: <1561038349-17105-2-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/mips: Fix if-else-switch-case arms checkpatch errors in translate.cAleksandar Markovic1-72/+133
Remove if-else-switch-case-arms-related checkpatch errors. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1561037595-14413-5-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/mips: Fix some space checkpatch errors in translate.cAleksandar Markovic1-118/+122
Remove some space-related checkpatch warning. Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Aleksandar Rikalo <arikalo@wavecomp.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1561037595-14413-4-git-send-email-aleksandar.markovic@rt-rk.com>
2019-06-21target/i386: kvm: Re-inject #DB to guest with updated DR6Liran Alon1-0/+3
If userspace (QEMU) debug guest, when #DB is raised in guest and intercepted by KVM, KVM forwards information on #DB to userspace instead of injecting #DB to guest. While doing so, KVM don't update vCPU DR6 but instead report the #DB DR6 value to userspace for further handling. See KVM's handle_exception() DB_VECTOR handler. QEMU handler for this case is kvm_handle_debug(). This handler basically checks if #DB is related to one of user set hardware breakpoints and if not, it re-inject #DB into guest. The re-injection is done by setting env->exception_injected to #DB which will later be passed as events.exception.nr to KVM_SET_VCPU_EVENTS ioctl by kvm_put_vcpu_events(). However, in case userspace re-injects #DB, KVM expects userspace to set vCPU DR6 as reported to userspace when #DB was intercepted! Otherwise, KVM_REQ_EVENT handler will inject #DB with wrong DR6 to guest. Fix this issue by updating vCPU DR6 appropriately when re-inject #DB to guest. Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-5-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: kvm: Use symbolic constant for #DB/#BP exception constantsLiran Alon1-4/+4
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-4-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21KVM: Introduce kvm_arch_destroy_vcpu()Liran Alon6-0/+42
Simiar to how kvm_init_vcpu() calls kvm_arch_init_vcpu() to perform arch-dependent initialisation, introduce kvm_arch_destroy_vcpu() to be called from kvm_destroy_vcpu() to perform arch-dependent destruction. This was added because some architectures (Such as i386) currently do not free memory that it have allocated in kvm_arch_init_vcpu(). Suggested-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Maran Wilson <maran.wilson@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20190619162140.133674-3-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: kvm: Delete VMX migration blocker on vCPU init failureLiran Alon1-2/+5
Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker") added migration blocker for vCPU exposed with Intel VMX because QEMU doesn't yet contain code to support migration of nested virtualization workloads. However, that commit missed adding deletion of the migration blocker in case init of vCPU failed. Similar to invtsc_mig_blocker. This commit fix that issue. Fixes: d98f26073beb ("target/i386: kvm: add VMX migration blocker") Signed-off-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Maran Wilson <maran.wilson@oracle.com> Message-Id: <20190619162140.133674-2-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21target/i386: define a new MSR based feature word - FEAT_CORE_CAPABILITYXiaoyao Li3-1/+35
MSR IA32_CORE_CAPABILITY is a feature-enumerating MSR, which only enumerates the feature split lock detection (via bit 5) by now. The existence of MSR IA32_CORE_CAPABILITY is enumerated by CPUID.7_0:EDX[30]. The latest kernel patches about them can be found here: https://lkml.org/lkml/2019/4/24/1909 Signed-off-by: Xiaoyao Li <xiaoyao.li@linux.intel.com> Message-Id: <20190617153654.916-1-xiaoyao.li@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: add support for Direct Mode for Hyper-V synthetic timersVitaly Kuznetsov4-0/+13
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for an interrupt instead of VMBus message). This new capability is only announced in KVM_GET_SUPPORTED_HV_CPUID. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-10-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: hv-evmcs requires hv-vapicVitaly Kuznetsov1-1/+2
Enlightened VMCS is enabled by writing to a field in VP assist page and these require virtual APIC. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-9-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: hv-tlbflush/ipi require hv-vpindexVitaly Kuznetsov1-2/+4
The corresponding hypercalls require using VP indexes. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-8-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: hv-stimer requires hv-time and hv-synicVitaly Kuznetsov1-4/+19
Synthetic timers operate in hv-time time and Windows won't use these without SynIC. Add .dependencies field to kvm_hyperv_properties[] and a generic mechanism to check dependencies between features. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-7-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: implement 'hv-passthrough' modeVitaly Kuznetsov3-14/+77
In many case we just want to give Windows guests all currently supported Hyper-V enlightenments and that's where this new mode may come handy. We pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID. hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as we may want to check them later (and we actually do for hv_runtime, hv_synic,...). 'hv-passthrough' is a development only feature, a migration blocker is added to prevent issues while migrating between hosts with different feature sets. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-6-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: move Hyper-V CPUID filling to hyperv_handle_properties()Vitaly Kuznetsov1-73/+90
Let's consolidate Hyper-V features handling in hyperv_handle_properties(). The change is necessary to support 'hv-passthrough' mode as we'll be just copying CPUIDs from KVM instead of filling them in. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-4-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUIDVitaly Kuznetsov1-118/+356
KVM now supports reporting supported Hyper-V features through CPUID (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be the only way to announce new functionality and this has already happened with Direct Mode stimers. While we could just support KVM_GET_SUPPORTED_HV_CPUID for new features, it seems to be beneficial to use it for all Hyper-V enlightenments when possible. This way we can implement 'hv-all' pass-through mode giving the guest all supported Hyper-V features even when QEMU knows nothing about them. Implementation-wise we create a new kvm_hyperv_properties structure defining Hyper-V features, get_supported_hv_cpuid()/ get_supported_hv_cpuid_legacy() returning the supported CPUID set and a bit over-engineered hv_cpuid_check_and_set() which we will also be used to set cpu->hyperv_* properties for 'hv-all' mode. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21i386/kvm: convert hyperv enlightenments properties from bools to bitsVitaly Kuznetsov5-79/+89
Representing Hyper-V properties as bits will allow us to check features and dependencies between them in a natural way. Suggested-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20190517141924.19024-2-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-21hax: Honor CPUState::haltedColin Xu1-2/+34
QEMU tracks whether a vcpu is halted using CPUState::halted. E.g., after initialization or reset, halted is 0 for the BSP (vcpu 0) and 1 for the APs (vcpu 1, 2, ...). A halted vcpu should not be handed to the hypervisor to run (e.g. hax_vcpu_run()). Under HAXM, Android Emulator sometimes boots into a "vcpu shutdown request" error while executing in SeaBIOS, with the HAXM driver logging a guest triple fault in vcpu 1, 2, ... at RIP 0x3. That is ultimately because the HAX accelerator asks HAXM to run those APs when they are still in the halted state. Normally, the vcpu thread for an AP will start by looping in qemu_wait_io_event(), until the BSP kicks it via a pair of IPIs (INIT followed by SIPI). But because the HAX accelerator does not honor cpu->halted, it allows the AP vcpu thread to proceed to hax_vcpu_run() as soon as it receives any kick, even if the kick does not come from the BSP. It turns out that emulator has a worker thread which periodically kicks every vcpu thread (possibly to collect CPU usage data), and if one of these kicks comes before those by the BSP, the AP will start execution from the wrong RIP, resulting in the aforementioned SMP boot failure. The solution is inspired by the KVM accelerator (credit to Chuanxiao Dong <chuanxiao.dong@intel.com> for the pointer): 1. Get rid of questionable logic that unconditionally resets cpu->halted before hax_vcpu_run(). Instead, only reset it at the right moments (there are only a few "unhalt" events). 2. Add a check for cpu->halted before hax_vcpu_run(). Note that although the non-Unrestricted Guest (!ug_platform) code path also forcibly resets cpu->halted, it is left untouched, because only the UG code path supports SMP guests. The patch is first merged to android emulator with Change-Id: I9c5752cc737fd305d7eace1768ea12a07309d716 Cc: Yu Ning <yu.ning@intel.com> Cc: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Message-Id: <20190610021939.13669-1-colin.xu@intel.com>
2019-06-18target/arm: Check for dp support for dp VFM, not spPeter Maydell1-4/+4
In commit 1120827fa182f0e7622 we accidentally put the "UNDEF unless FPU has double-precision support" check in the single-precision VFM function. Put it in the dp function where it belongs. Fixes: 1120827fa182f0e7622 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190617160130.3207-1-peter.maydell@linaro.org
2019-06-17target/arm: Only implement doubles if the FPU supports themPeter Maydell2-0/+90
The architecture permits FPUs which have only single-precision support, not double-precision; Cortex-M4 and Cortex-M33 are both like that. Add the necessary checks on the MVFR0 FPDP field so that we UNDEF any double-precision instructions on CPUs like this. Note that even if FPDP==0 the insns like VMOV-to/from-gpreg, VLDM/VSTM, VLDR/VSTR which take double precision registers still exist. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190614104457.24703-3-peter.maydell@linaro.org
2019-06-17target/arm: Fix typos in trans function prototypesPeter Maydell1-14/+14
In several places cut and paste errors meant we were using the wrong type for the 'arg' struct in trans_ functions called by the decodetree decoder, because we were using the _sp version of the struct in the _dp function. These were harmless, because the two structs were identical and so decodetree made them typedefs of the same underlying structure (and we'd have had a compile error if they were not harmless), but we should clean them up anyway. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190614104457.24703-2-peter.maydell@linaro.org
2019-06-17target/arm: Remove unused cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1dPeter Maydell1-10/+2
Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d. cpu_M0 is still used by the iwmmxt code, and cpu_V0 and cpu_V1 are used by both iwmmxt and Neon. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-13-peter.maydell@linaro.org
2019-06-17target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16Peter Maydell1-15/+11
Remove some old constructns from NEON_2RM_VCVT_F16_F32 code: * don't use CPU_F0s * don't use tcg_gen_st_f32 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-12-peter.maydell@linaro.org
2019-06-17target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32Peter Maydell1-15/+12
Remove some old constructs from NEON_2RM_VCVT_F16_F32 code: * don't use cpu_F0s * don't use tcg_gen_ld_f32 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-11-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s in Neon VCVT fixed-point opsPeter Maydell1-34/+28
Stop using cpu_F0s in the Neon VCVT fixed-point operations. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-10-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for Neon f32/s32 VCVTPeter Maydell1-60/+22
Stop using cpu_F0s for the Neon f32/s32 VCVT operations. Since this is the last user of cpu_F0s in the Neon 2rm-op loop, we can remove the handling code for it too. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-9-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_FPeter Maydell1-3/+3
Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-8-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US]Peter Maydell1-4/+3
Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-7-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for NEON_2RM_VRINT*Peter Maydell1-5/+3
Switch NEON_2RM_VRINT* away from using cpu_F0s. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-6-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_FPeter Maydell1-11/+2
Switch NEON_2RM_VABS_F away from using cpu_F0s. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-5-peter.maydell@linaro.org
2019-06-17target/arm: Stop using cpu_F0s for NEON_2RM_VABS_FPeter Maydell1-11/+8
Where Neon instructions are floating point operations, we mostly use the old VFP utility functions like gen_vfp_abs() which work on the TCG globals cpu_F0s and cpu_F1s. The Neon for-each-element loop conditionally loads the inputs into either a plain old TCG temporary for most operations or into cpu_F0s for float operations, and similarly stores back either cpu_F0s or the temporary. Switch NEON_2RM_VABS_F away from using cpu_F0s, and update neon_2rm_is_float_op() accordingly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-4-peter.maydell@linaro.org
2019-06-17target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_immPeter Maydell2-28/+10
The AArch32 VMOV (immediate) instruction uses the same VFP encoded immediate format we already handle in vfp_expand_imm(). Use that function rather than hand-decoding it. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-3-peter.maydell@linaro.org
2019-06-17target/arm: Move vfp_expand_imm() to translate.[ch]Peter Maydell4-33/+40
We want to use vfp_expand_imm() in the AArch32 VFP decode; move it from the a64-only header/source file to the AArch32 one (which is always compiled even for AArch64). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190613163917.28589-2-peter.maydell@linaro.org
2019-06-17target/arm: Allow M-profile CPUs to disable the DSP extension via CPU propertyPeter Maydell2-0/+31
Allow the DSP extension to be disabled via a CPU property for M-profile CPUs. (A and R-profile CPUs don't have this extension as a defined separate optional architecture extension, so they don't need the property.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-3-peter.maydell@linaro.org
2019-06-17target/arm: Allow VFP and Neon to be disabled via a CPU propertyPeter Maydell2-6/+148
Allow VFP and neon to be disabled via a CPU property. As with the "pmu" property, we only allow these features to be removed from CPUs which have it by default, not added to CPUs which don't have it. The primary motivation here is to be able to optionally create Cortex-M33 CPUs with no FPU, but we provide switches for both VFP and Neon because the two interact: * AArch64 can't have one without the other * Some ID register fields only change if both are disabled Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-2-peter.maydell@linaro.org
2019-06-13target/arm: Fix short-vector increment behaviourPeter Maydell1-40/+60
For VFP short vectors, the VFP registers are divided into a series of banks: for single-precision these are s0-s7, s8-s15, s16-s23 and s24-s31; for double-precision they are d0-d3, d4-d7, ... d28-d31. Some banks are "scalar" meaning that use of a register within them triggers a pure-scalar or mixed vector-scalar operation rather than a full vector operation. The scalar banks are s0-s7, d0-d3 and d16-d19. When using a bank as part of a vector operation, we iterate through it, increasing the register number by the specified stride each time, and wrapping around to the beginning of the bank. Unfortunately our calculation of the "increment" part of this was incorrect: vd = ((vd + delta_d) & (bank_mask - 1)) | (vd & bank_mask) will only do the intended thing if bank_mask has exactly one set high bit. For instance for doubles (bank_mask = 0xc), if we start with vd = 6 and delta_d = 2 then vd is updated to 12 rather than the intended 4. This only causes problems in the unlikely case that the starting register is not the first in its bank: if the register number doesn't have to wrap around then the expression happens to give the right answer. Fix this bug by abstracting out the "check whether register is in a scalar bank" and "advance register within bank" operations to utility functions which use the right bit masking operations. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-06-13target/arm: Convert float-to-integer VCVT insns to decodetreePeter Maydell3-239/+80
Convert the float-to-integer VCVT instructions to decodetree. Since these are the last unconverted instructions, we can delete the old decoder structure entirely now. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-06-13target/arm: Convert VCVT fp/fixed-point conversion insns to decodetreePeter Maydell3-55/+136
Convert the VCVT (between floating-point and fixed-point) instructions to decodetree. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.1 at 2024-08-24 05:29:31 +0000