summaryrefslogtreecommitdiffstats
path: root/target/arm/cpu.c
Commit message (Collapse)AuthorAgeFilesLines
* target/arm: Remove EL2 and EL3 setup from user-onlyRichard Henderson2020-03-051-6/+0Star
| | | | | | | | | | We have disabled EL2 and EL3 for user-only, which means that these registers "don't exist" and should not be set. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200229012811.24129-5-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Disable has_el2 and has_el3 for user-onlyRichard Henderson2020-03-051-2/+4
| | | | | | | | | | | | | | In arm_cpu_reset, we configure many system registers so that user-only behaves as it should with a minimum of ifdefs. However, we do not set all of the system registers as required for a cpu with EL2 and EL3. Disabling EL2 and EL3 mean that we will not look at those registers, which means that we don't have to worry about configuring them. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200229012811.24129-4-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Implement (trivially) ARMv8.2-TTCNPPeter Maydell2020-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The ARMv8.2-TTCNP extension allows an implementation to optimize by sharing TLB entries between multiple cores, provided that software declares that it's ready to deal with this by setting a CnP bit in the TTBRn_ELx. It is mandatory from ARMv8.2 onward. For QEMU's TLB implementation, sharing TLB entries between different cores would not really benefit us and would be a lot of work to implement. So we implement this extension in the "trivial" manner: we allow the guest to set and read back the CnP bit, but don't change our behaviour (this is an architecturally valid implementation choice). The only code path which looks at the TTBRn_ELx values for the long-descriptor format where the CnP bit is defined is already doing enough masking to not get confused when the CnP bit at the bottom of the register is set, so we can simply add a comment noting why we're relying on that mask. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200225193822.18874-1-peter.maydell@linaro.org
* target/arm: Remove ARM_FEATURE_VFP*Richard Henderson2020-02-281-25/+0Star
| | | | | | | | | | We have converted all tests against these features to ISAR tests. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200224222232.13807-15-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmacRichard Henderson2020-02-281-1/+5
| | | | | | | | | | | | | | | | All remaining tests for VFP4 are for fused multiply-add insns. Since the MVFR1 field is used for both VFP and NEON, move its adjustment from the !has_neon block to the (!has_vfp && !has_neon) block. Test for vfp of the appropraite width alongside the test for simdfmac within translate-vfp.inc.c. Within disas_neon_data_insn, we have already tested for ARM_FEATURE_NEON. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200224222232.13807-10-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Add isar_feature_aa64_fp_simd, isar_feature_aa32_vfpRichard Henderson2020-02-281-3/+6
| | | | | | | | | | | | | | | We cannot easily create "any" functions for these, because the ID_AA64PFR0 fields for FP and SIMD signal "enabled" with zero. Which means that an aarch32-only cpu will return incorrect results when testing the aarch64 registers. To use these, we must either have context or additionally test vs ARM_FEATURE_AARCH64. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200224222232.13807-5-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Add isar_feature_aa32_vfp_simdRichard Henderson2020-02-281-2/+2
| | | | | | | | | | | Use this in the places that were checking ARM_FEATURE_VFP, and are obviously testing for the existance of the register set as opposed to testing for some particular instruction extension. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200224222232.13807-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Set MVFR0.FPSP for ARMv5 cpusRichard Henderson2020-02-211-4/+6
| | | | | | | | | | | We are going to convert FEATURE tests to ISAR tests, so FPSP needs to be set for these cpus, like we have already for FPDP. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214181547.21408-5-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Use isar_feature_aa32_simd_r32 more placesRichard Henderson2020-02-211-5/+4Star
| | | | | | | | | | | Many uses of ARM_FEATURE_VFP3 are testing for the number of simd registers implemented. Use the proper test vs MVFR0.SIMDReg. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214181547.21408-4-richard.henderson@linaro.org [PMM: fix typo in commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Correctly implement ACTLR2, HACTLR2Peter Maydell2020-02-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | The ACTLR2 and HACTLR2 AArch32 system registers didn't exist in ARMv7 or the original ARMv8. They were later added as optional registers, whose presence is signaled by the ID_MMFR4.AC2 field. From ARMv8.2 they are mandatory (ie ID_MMFR4.AC2 must be non-zero). We implemented HACTLR2 in commit 0e0456ab8895a5e85, but we incorrectly made it exist for all v8 CPUs, and we didn't implement ACTLR2 at all. Sort this out by implementing both registers only when they are supposed to exist, and setting the ID_MMFR4 bit for -cpu max. Note that this removes HACTLR2 from our Cortex-A53, -A47 and -A72 CPU models; this is correct, because those CPUs do not implement this register. Fixes: 0e0456ab8895a5e85 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-22-peter.maydell@linaro.org
* target/arm: Test correct register in aa32_pan and aa32_ats1e1 checksPeter Maydell2020-02-211-52/+52
| | | | | | | | | | | | | | | The isar_feature_aa32_pan and isar_feature_aa32_ats1e1 functions are supposed to be testing fields in ID_MMFR3; but a cut-and-paste error meant we were looking at MVFR0 instead. Fix the functions to look at the right register; this requires us to move at least id_mmfr3 to the ARMISARegisters struct; we choose to move all the ID_MMFRn registers for consistency. Fixes: 3d6ad6bb466f Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-19-peter.maydell@linaro.org
* target/arm: Move DBGDIDR into ARMISARegistersPeter Maydell2020-02-211-4/+4
| | | | | | | | | | We're going to want to read the DBGDIDR register from KVM in a subsequent commit, which means it needs to be in the ARMISARegisters sub-struct. Move it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200214175116.9164-12-peter.maydell@linaro.org
* target/arm: Add _aa64_ and _any_ versions of pmu_8_1 isar checksPeter Maydell2020-02-211-1/+2
| | | | | | | | | | | | | | | | Add the 64-bit version of the "is this a v8.1 PMUv3?" ID register check function, and the _any_ version that checks for either AArch32 or AArch64 support. We'll use this in a later commit. We don't (yet) do any isar_feature checks on ID_AA64DFR1_EL1, but we move id_aa64dfr1 into the ARMISARegisters struct with id_aa64dfr0, for consistency. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-10-peter.maydell@linaro.org
* target/arm: Define an aa32_pmu_8_1 isar feature test functionPeter Maydell2020-02-211-14/+14
| | | | | | | | | | | | Instead of open-coding a check on the ID_DFR0 PerfMon ID register field, create a standardly-named isar_feature for "does AArch32 have a v8.1 PMUv3" and use it. This entails moving the id_dfr0 field into the ARMISARegisters struct. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-9-peter.maydell@linaro.org
* target/arm: Use FIELD macros for clearing ID_DFR0 PERFMON fieldPeter Maydell2020-02-211-1/+1
| | | | | | | | | | We already define FIELD macros for ID_DFR0, so use them in the one place where we're doing direct bit value manipulation. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-8-peter.maydell@linaro.org
* target/arm: Add and use FIELD definitions for ID_AA64DFR0_EL1Peter Maydell2020-02-211-1/+1
| | | | | | | | | | Add FIELD() definitions for the ID_AA64DFR0_EL1 and use them where we currently have hard-coded bit values. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-7-peter.maydell@linaro.org
* target/arm: Add _aa32_ to isar_feature functions testing 32-bit ID registersPeter Maydell2020-02-211-2/+4
| | | | | | | | | | | | | | | | | | Enforce a convention that an isar_feature function that tests a 32-bit ID register always has _aa32_ in its name, and one that tests a 64-bit ID register always has _aa64_ in its name. We already follow this except for three cases: thumb_div, arm_div and jazelle, which all need _aa32_ adding. (As noted in the comment, isar_feature_aa32_fp16_arith() is an exception in that it currently tests ID_AA64PFR0_EL1, but will switch to MVFR1 once we've properly implemented FP16 for AArch32.) Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200214175116.9164-2-peter.maydell@linaro.org
* target/arm: Enable ARMv8.2-ATS1E1 in -cpu maxRichard Henderson2020-02-131-0/+4
| | | | | | | | | This includes enablement of ARMv8.1-PAN. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200208125816.14954-17-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Raise only one interrupt in arm_cpu_exec_interruptRichard Henderson2020-02-071-18/+12Star
| | | | | | | | | | | | | | | The fall through organization of this function meant that we would raise an interrupt, then might overwrite that with another. Since interrupt prioritization is IMPLEMENTATION DEFINED, we can recognize these in any order we choose. Unify the code to raise the interrupt in a block at the end. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200206105448.4726-42-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Use bool for unmasked in arm_excp_unmaskedRichard Henderson2020-02-071-3/+3
| | | | | | | | | | The value computed is fully boolean; using int8_t is odd. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200206105448.4726-41-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Pass more cpu state to arm_excp_unmaskedRichard Henderson2020-02-071-10/+12
| | | | | | | | | | | Avoid redundant computation of cpu state by passing it in from the caller, which has already computed it for itself. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200206105448.4726-40-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Move arm_excp_unmasked to cpu.cRichard Henderson2020-02-071-0/+119
| | | | | | | | | | | This inline function has one user in cpu.c, and need not be exposed otherwise. Code movement only, with fixups for checkpatch. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200206105448.4726-39-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Add the hypervisor virtual counterRichard Henderson2020-02-071-1/+2
| | | | | | | | Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200206105448.4726-26-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm/cpu: Add the kvm-no-adjvtime CPU propertyAndrew Jones2020-01-301-0/+2
| | | | | | | | | | | | kvm-no-adjvtime is a KVM specific CPU property and a first of its kind. To accommodate it we also add kvm_arm_add_vcpu_properties() and a KVM specific CPU properties description to the CPU features document. Signed-off-by: Andrew Jones <drjones@redhat.com> Message-id: 20200120101023.16030-7-drjones@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2020-01-271-27/+14Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Register qdev properties as class properties (Marc-André) * Cleanups (Philippe) * virtio-scsi fix (Pan Nengyuan) * Tweak Skylake-v3 model id (Kashyap) * x86 UCODE_REV support and nested live migration fix (myself) * Advisory mode for pvpanic (Zhenwei) # gpg: Signature made Fri 24 Jan 2020 20:16:23 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (58 commits) build-sys: clean up flags included in the linker command line target/i386: Add the 'model-id' for Skylake -v3 CPU models qdev: use object_property_help() qapi/qmp: add ObjectPropertyInfo.default-value qom: introduce object_property_help() qom: simplify qmp_device_list_properties() vl: print default value in object help qdev: register properties as class properties qdev: move instance properties to class properties qdev: rename DeviceClass.props qdev: set properties with device_class_set_props() object: return self in object_ref() object: release all props object: add object_class_property_add_link() object: express const link with link property object: add direct link flag object: rename link "child" to "target" object: check strong flag with & object: do not free class properties object: add object_property_set_default ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * qdev: set properties with device_class_set_props()Marc-André Lureau2020-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * qdev: remove extraneous errorMarc-André Lureau2020-01-241-24/+12Star
| | | | | | | | | | | | | | | | | | All callers use error_abort, and even the function itself calls with error_abort. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-4-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * cpu: Use cpu_class_set_parent_reset()Greg Kurz2020-01-241-2/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert all targets to use cpu_class_set_parent_reset() with the following coccinelle script: @@ type CPUParentClass; CPUParentClass *pcc; CPUClass *cc; identifier parent_fn; identifier child_fn; @@ +cpu_class_set_parent_reset(cc, child_fn, &pcc->parent_fn); -pcc->parent_fn = cc->reset; ... -cc->reset = child_fn; Signed-off-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <157650847817.354886.7047137349018460524.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | target/arm: add PMU feature to cortex-r5 and cortex-r5fClement Deschamps2020-01-231-0/+1
|/ | | | | | | | | | The PMU is not optional on cortex-r5 and cortex-r5f (see the "Features" chapter of the Technical Reference Manual). Signed-off-by: Clement Deschamps <clement.deschamps@greensocs.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200114105918.2366370-1-clement.deschamps@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Prepare generic timer for per-platform CNTFRQAndrew Jeffery2019-12-201-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASPEED AST2600 clocks the generic timer at the rate of HPLL. On recent firmwares this is at 1125MHz, which is considerably quicker than the assumed 62.5MHz of the current generic timer implementation. The delta between the value as read from CNTFRQ and the true rate of the underlying QEMUTimer leads to sticky behaviour in AST2600 guests. Add a feature-gated property exposing CNTFRQ for ARM CPUs providing the generic timer. This allows platforms to configure CNTFRQ (and the associated QEMUTimer) to the appropriate frequency prior to starting the guest. As the platform can now determine the rate of CNTFRQ we're exposed to limitations of QEMUTimer that didn't previously materialise: In the course of emulation we need to arbitrarily and accurately convert between guest ticks and time, but we're constrained by QEMUTimer's use of an integer scaling factor. The effect is QEMUTimer cannot exactly capture the period of frequencies that do not cleanly divide NANOSECONDS_PER_SECOND for scaling ticks to time. As such, provide an equally inaccurate scaling factor for scaling time to ticks so at least a self-consistent inverse relationship holds. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: a22db9325f96e39f76e3c2baddcb712149f46bf2.1576215453.git-series.andrew@aj.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Abstract the generic timer frequencyAndrew Jeffery2019-12-201-0/+8
| | | | | | | | | | | | | | | | | | | | Prepare for SoCs such as the ASPEED AST2600 whose firmware configures CNTFRQ to values significantly larger than the static 62.5MHz value currently derived from GTIMER_SCALE. As the OS potentially derives its timer periods from the CNTFRQ value the lack of support for running QEMUTimers at the appropriate rate leads to sticky behaviour in the guest. Substitute the GTIMER_SCALE constant with use of a helper to derive the period from gt_cntfrq_hz stored in struct ARMCPU. Initially set gt_cntfrq_hz to the frequency associated with GTIMER_SCALE so current behaviour is maintained. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 40bd8df043f66e1ccfb3e9482999d099ac72bb2e.1576215453.git-series.andrew@aj.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Add support for cortex-m7 CPUChristophe Lyon2019-12-161-0/+33
| | | | | | | | | | | | | | | This is derived from cortex-m4 description, adding DP support and FPv5 instructions with the corresponding flags in isar and mvfr2. Checked that it could successfully execute vrinta.f32 s15, s15 while cortex-m4 emulation rejects it with "illegal instruction". Signed-off-by: Christophe Lyon <christophe.lyon@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20191025090841.10299-1-christophe.lyon@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm/kvm: host cpu: Add support for sve<N> propertiesAndrew Jones2019-11-011-0/+3
| | | | | | | | | | | | | | | | | | | | Allow cpu 'host' to enable SVE when it's available, unless the user chooses to disable it with the added 'sve=off' cpu property. Also give the user the ability to select vector lengths with the sve<N> properties. We don't adopt 'max' cpu's other sve property, sve-max-vq, because that property is difficult to use with KVM. That property assumes all vector lengths in the range from 1 up to and including the specified maximum length are supported, but there may be optional lengths not supported by the host in that range. With KVM one must be more specific when enabling vector lengths. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Message-id: 20191031142734.8590-10-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm/cpu64: max cpu: Introduce sve<N> propertiesAndrew Jones2019-11-011-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce cpu properties to give fine control over SVE vector lengths. We introduce a property for each valid length up to the current maximum supported, which is 2048-bits. The properties are named, e.g. sve128, sve256, sve384, sve512, ..., where the number is the number of bits. See the updates to docs/arm-cpu-features.rst for a description of the semantics and for example uses. Note, as sve-max-vq is still present and we'd like to be able to support qmp_query_cpu_model_expansion with guests launched with e.g. -cpu max,sve-max-vq=8 on their command lines, then we do allow sve-max-vq and sve<N> properties to be provided at the same time, but this is not recommended, and is why sve-max-vq is not mentioned in the document. If sve-max-vq is provided then it enables all lengths smaller than and including the max and disables all lengths larger. It also has the side-effect that no larger lengths may be enabled and that the max itself cannot be disabled. Smaller non-power-of-two lengths may, however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a guest the vector lengths 128, 256, and 512 bits. This patch has been co-authored with Richard Henderson, who reworked the target/arm/cpu64.c changes in order to push all the validation and auto-enabling/disabling steps into the finalizer, resulting in a nice LOC reduction. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-5-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Allow SVE to be disabled via a CPU propertyAndrew Jones2019-11-011-1/+2
| | | | | | | | | | | | | | | | | Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via a CPU property") we can disable the 'max' cpu model's VFP and neon features, but there's no way to disable SVE. Add the 'sve=on|off' property to give it that flexibility. We also rename cpu_max_get/set_sve_vq to cpu_max_get/set_sve_max_vq in order for them to follow the typical *_get/set_<property-name> pattern. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Beata Michalska <beata.michalska@linaro.org> Message-id: 20191031142734.8590-4-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Rebuild hflags at EL changesRichard Henderson2019-10-241-0/+1
| | | | | | | | | Begin setting, but not relying upon, env->hflags. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191023150057.25731-17-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* intc/arm_gic: Support IRQ injection for more than 256 vpusEric Auger2019-10-151-6/+4Star
| | | | | | | | | | | | | | | | | | | | | | Host kernels that expose the KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 capability allow injection of interrupts along with vcpu ids larger than 255. Let's encode the vpcu id on 12 bits according to the upgraded KVM_IRQ_LINE ABI when needed. Given that we have two callsites that need to assemble the value for kvm_set_irq(), a new helper routine, kvm_arm_set_irq is introduced. Without that patch qemu exits with "kvm_set_irq: Invalid argument" message. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Acked-by: Marc Zyngier <maz@kernel.org> Message-id: 20191003154640.22451-3-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm/cpu: Ensure we can use the pmu with kvmAndrew Jones2019-08-161-5/+25
| | | | | | | | | | | | We first convert the pmu property from a static property to one with its own accessors. Then we use the set accessor to check if the PMU is supported when using KVM. Indeed a 32-bit KVM host does not support the PMU, so this check will catch an attempt to use it at property-set time. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Avoid bogus NSACR traps on M-profile without Security ExtensionPeter Maydell2019-08-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | In Arm v8.0 M-profile CPUs without the Security Extension and also in v7M CPUs, there is no NSACR register. However, the code we have to handle the FPU does not always check whether the ARM_FEATURE_M_SECURITY bit is set before testing whether env->v7m.nsacr permits access to the FPU. This means that for a CPU with an FPU but without the Security Extension we would always take a bogus fault when trying to stack the FPU registers on an exception entry. We could fix this by adding extra feature bit checks for all uses, but it is simpler to just make the internal value of nsacr 0xcff ("all non-secure accesses allowed"), since this is not guest visible when the Security Extension is not present. This allows us to continue to follow the Arm ARM pseudocode which takes a similar approach. (In particular, in the v8.1 Arm ARM the register is documented as reading as 0xcff in this configuration.) Fixes: https://bugs.launchpad.net/qemu/+bug/1838475 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20190801105742.20036-1-peter.maydell@linaro.org
* target/arm: Limit ID register assertions to TCGPeter Maydell2019-07-221-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In arm_cpu_realizefn() we make several assertions about the values of guest ID registers: * if the CPU provides AArch32 v7VE or better it must advertise the ARM_DIV feature * if the CPU provides AArch32 A-profile v6 or better it must advertise the Jazelle feature These are essentially consistency checks that our ID register specifications in cpu.c didn't accidentally miss out a feature, because increasingly the TCG emulation gates features on the values in ID registers rather than using old-style checks of ARM_FEATURE_FOO bits. Unfortunately, these asserts can cause problems if we're running KVM, because in that case we don't control the values of the ID registers -- we read them from the host kernel. In particular, if the host kernel is older than 4.15 then it doesn't expose the ID registers via the KVM_GET_ONE_REG ioctl, and we set up dummy values for some registers and leave the rest at zero. (See the comment in target/arm/kvm64.c kvm_arm_get_host_cpu_features().) This set of dummy values is not sufficient to pass our assertions, and so on those kernels running an AArch32 guest on AArch64 will assert. We could provide a more sophisticated set of dummy ID registers in this case, but that still leaves the possibility of a host CPU which reports bogus ID register values that would cause us to assert. It's more robust to only do these ID register checks if we're using TCG, as that is the only case where this is truly a QEMU code bug. Reported-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190718125928.20147-1-peter.maydell@linaro.org Fixes: https://bugs.launchpad.net/qemu/+bug/1830864 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026Peter Maydell2019-07-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | The ARMv5 architecture didn't specify detailed per-feature ID registers. Now that we're using the MVFR0 register fields to gate the existence of VFP instructions, we need to set up the correct values in the cpu->isar structure so that we still provide an FPU to the guest. This fixes a regression in the arm926 and arm1026 CPUs, which are the only ones that both have VFP and are ARMv5 or earlier. This regression was introduced by the VFP refactoring, and more specifically by commits 1120827fa182f0e76 and 266bd25c485597c, which accidentally disabled VFP short-vector support and double-precision support on these CPUs. Fixes: 1120827fa182f0e Fixes: 266bd25c485597c Fixes: https://bugs.launchpad.net/qemu/+bug/1836192 Reported-by: Christophe Lyon <christophe.lyon@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Christophe Lyon <christophe.lyon@linaro.org> Message-id: 20190711131241.22231-1-peter.maydell@linaro.org
* target/arm: report ARMv8-A FP support for AArch32 -cpu maxAlex Bennée2019-07-151-0/+4
| | | | | | | | | | | | | | When we converted to using feature bits in 602f6e42cfbf we missed out the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for -cpu max configurations. This caused a regression in the GCC test suite. Fix this by setting the appropriate bits in mvfr1.FPHP to report ARMv8-A with FP support (but not ARMv8.2-FP16). Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190711103737.10017-1-alex.bennee@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm: Replace global smp variables with machine smp propertiesLike Xu2019-07-051-1/+7
| | | | | | | | | | | | | | | The global smp variables in arm are replaced with smp machine properties. The init_cpus() and *_create_rpu() are refactored to pass MachineState. A local variable of the same name would be introduced in the declaration phase if it's used widely in the context OR replace it on the spot if it's only used once. No semantic changes. Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190518205428.90532-9-like.xu@linux.intel.com> [ehabkost: Fix hw/arm/sbsa-ref.c and hw/arm/aspeed.c] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* target/arm: Move debug routines to debug_helper.cPhilippe Mathieu-Daudé2019-07-041-6/+3Star
| | | | | | | | | These routines are TCG specific. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190701194942.10092-2-philmd@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Move TLB related routines to tlb_helper.cPhilippe Mathieu-Daudé2019-07-011-2/+4
| | | | | | | | | | | | These routines are TCG specific. The arm_deliver_fault() function is only used within the new helper. Make it static. Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190701132516.26392-13-philmd@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Move CPU state dumping routines to cpu.cPhilippe Mathieu-Daudé2019-07-011-0/+226
| | | | | | | | Suggested-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190701132516.26392-11-philmd@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Allow M-profile CPUs to disable the DSP extension via CPU propertyPeter Maydell2019-06-171-0/+29
| | | | | | | | | | | | 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
* target/arm: Allow VFP and Neon to be disabled via a CPU propertyPeter Maydell2019-06-171-6/+144
| | | | | | | | | | | | | | | | | | 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
* target/arm: Explicitly enable VFP short-vectors for aarch32 -cpu maxPeter Maydell2019-06-131-0/+4
| | | | | | | | | | | | | | | At the moment our -cpu max for AArch32 supports VFP short-vectors because we always implement them, even for CPUs which should not have them. The following commits are going to switch to using the correct ID-register-check to enable or disable short vector support, so we need to turn it on explicitly for -cpu max, because Cortex-A15 doesn't implement it. We don't enable this for the AArch64 -cpu max, because the v8A architecture never supports short-vectors. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
* target/arm: Fix Cortex-R5F MVFR valuesPeter Maydell2019-06-131-0/+2
| | | | | | | | | The Cortex-R5F initfn was not correctly setting up the MVFR ID register values. Fill these in, since some subsequent patches will use ID register checks rather than CPU feature bit checks. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-02-03 23:41:45 +0100