aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-10hw/riscv/virt.c: fix the interrupts-extended property format of PLICYong-Xuan Wang1-20/+27
The interrupts-extended property of PLIC only has 2 * hart number fields when KVM enabled, copy 4 * hart number fields to fdt will expose some uninitialized value. In this patch, I also refactor the code about the setting of interrupts-extended property of PLIC for improved readability. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218090543.22353-1-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add PLIC in MADTSunil V L1-0/+29
Add PLIC structures for each socket in the MADT when system is configured with PLIC as the external interrupt controller. Signed-off-by: Haibo Xu <haibo1.xu@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-14-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add IO controllers and devicesSunil V L2-4/+76
Add basic IO controllers and devices like PCI, VirtIO and UART in the ACPI namespace. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-13-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt: Update GPEX MMIO related propertiesSunil V L2-15/+33
Update the GPEX host bridge properties related to MMIO ranges with values set for the virt machine. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-12-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/pci-host/gpex: Define properties for MMIO rangesSunil V L3-8/+45
ACPI DSDT generator needs information like ECAM range, PIO range, 32-bit and 64-bit PCI MMIO range etc related to the PCI host bridge. Instead of making these values machine specific, create properties for the GPEX host bridge with default value 0. During initialization, the firmware can initialize these properties with correct values for the platform. This basically allows DSDT generator code independent of the machine specific memory map accesses. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218150247.466427-11-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add MMU node in RHCTSunil V L1-1/+35
MMU type information is available via MMU node in RHCT. Add this node in RHCT. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-10-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add CMO information in RHCTSunil V L1-8/+56
When CMO related extensions like Zicboz, Zicbom and Zicbop are enabled, the block size for those extensions need to be communicated via CMO node in RHCT. Add CMO node in RHCT if any of those CMO extensions are detected. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-9-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add APLIC in the MADTSunil V L1-0/+34
Add APLIC structures for each socket in the MADT when system is configured with APLIC as the external wired interrupt controller. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-8-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add IMSIC in the MADTSunil V L1-0/+35
Add IMSIC structure in MADT when IMSIC is configured. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-7-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add AIA support in RINTCSunil V L1-4/+39
Update the RINTC structure in MADT with AIA related fields. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-6-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv: virt: Make few IMSIC macros and functions publicSunil V L2-24/+26
Some macros and static function related to IMSIC are defined in virt.c. They are required in virt-acpi-build.c. So, make them public. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-5-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/i386/acpi-microvm.c: Use common function to add virtio in DSDTSunil V L1-13/+2
With common function to add virtio in DSDT created now, update microvm code also to use it instead of duplicate code. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-4-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate virtio creation to common locationSunil V L4-28/+54
RISC-V also needs to create the virtio in DSDT in the same way as ARM. So, instead of duplicating the code, move this function to the device specific file which is common across architectures. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-3-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate fw_cfg creation to common locationSunil V L5-34/+43
RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid code duplication by moving the code in arm and riscv to a device specific file. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: rename riscv_reg_id() to riscv_reg_id_ulong()Daniel Henrique Barboza1-19/+21
kvm_riscv_reg_id() returns an id encoded with an ulong size, i.e. an u32 size when running TARGET_RISCV32 and u64 when running TARGET_RISCV64. Rename it to kvm_riscv_reg_id_ulong() to enhance code readability. It'll be in line with the existing kvm_riscv_reg_id_<size>() helpers. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: add RISCV_CONFIG_REG()Daniel Henrique Barboza1-14/+11
Create a RISCV_CONFIG_REG() macro, similar to what other regs use, to hide away some of the boilerplate. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change timer regs size to u64Daniel Henrique Barboza1-13/+13
KVM_REG_RISCV_TIMER regs are always u64 according to the KVM API, but at this moment we'll return u32 regs if we're running a RISCV32 target. Use the kvm_riscv_reg_id_u64() helper in RISCV_TIMER_REG() to fix it. Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64Daniel Henrique Barboza1-3/+8
KVM_REG_RISCV_FP_D regs are always u64 size. Using kvm_riscv_reg_id() in RISCV_FP_D_REG() ends up encoding the wrong size if we're running with TARGET_RISCV32. Create a new helper that returns a KVM ID with u64 size and use it with RISCV_FP_D_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change KVM_REG_RISCV_FP_F to u32Daniel Henrique Barboza1-3/+8
KVM_REG_RISCV_FP_F regs have u32 size according to the API, but by using kvm_riscv_reg_id() in RISCV_FP_F_REG() we're returning u64 sizes when running with TARGET_RISCV64. The most likely reason why no one noticed this is because we're not implementing kvm_cpu_synchronize_state() in RISC-V yet. Create a new helper that returns a KVM ID with u32 size and use it in RISCV_FP_F_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/cpu.c: fix machine IDs gettersDaniel Henrique Barboza1-6/+6
mvendorid is an uint32 property, mimpid/marchid are uint64 properties. But their getters are returning bools. The reason this went under the radar for this long is because we have no code using the getters. The problem can be seem via the 'qom-get' API though. Launching QEMU with the 'veyron-v1' CPU, a model with: VEYRON_V1_MVENDORID: 0x61f (1567) VEYRON_V1_MIMPID: 0x111 (273) VEYRON_V1_MARCHID: 0x8000000000010000 (9223372036854841344) This is what the API returns when retrieving these properties: (qemu) qom-get /machine/soc0/harts[0] mvendorid true (qemu) qom-get /machine/soc0/harts[0] mimpid true (qemu) qom-get /machine/soc0/harts[0] marchid true After this patch: (qemu) qom-get /machine/soc0/harts[0] mvendorid 1567 (qemu) qom-get /machine/soc0/harts[0] mimpid 273 (qemu) qom-get /machine/soc0/harts[0] marchid 9223372036854841344 Fixes: 1e34150045 ("target/riscv/cpu.c: restrict 'mvendorid' value") Fixes: a1863ad368 ("target/riscv/cpu.c: restrict 'mimpid' value") Fixes: d6a427e2c0 ("target/riscv/cpu.c: restrict 'marchid' value") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231211170732.2541368-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/pmp: Use hwaddr instead of target_ulong for RV32Ivan Klokov2-18/+16
The Sv32 page-based virtual-memory scheme described in RISCV privileged spec Section 5.3 supports 34-bit physical addresses for RV32, so the PMP scheme must support addresses wider than XLEN for RV32. However, PMP address register format is still 32 bit wide. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231123091214.20312-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Not allow write mstatus_vs without RVVLIU Zhiwei1-1/+4
If CPU does not implement the Vector extension, it usually means mstatus vs hardwire to zero. So we should not allow write a non-zero value to this field. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231215023313.1708-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Fix th.dcache.cval1 priviledge checkLIU Zhiwei1-1/+1
According to the specification, the th.dcache.cvall1 can be executed under all priviledges. The specification about xtheadcmo located in, https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadcmo/dcache_cval1.adoc Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Christoph Muellner <christoph.muellner@vrull.eu> Message-ID: <20231208094315.177-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: The whole vector register move instructions depend on vsewMax Chou1-2/+1
The RISC-V v spec 16.6 section says that the whole vector register move instructions operate as if EEW=SEW. So it should depends on the vsew field of vtype register. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231129170400.21251-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Add vill check for whole vector register move instructionsMax Chou1-2/+3
The ratified version of RISC-V V spec section 16.6 says that `The instructions operate as if EEW=SEW`. So the whole vector register move instructions depend on the vtype register that means the whole vector register move instructions should raise an illegal-instruction exception when vtype.vill=1. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231129170400.21251-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10util/fifo8: Introduce fifo8_peek_buf()Philippe Mathieu-Daudé2-4/+45
To be able to peek at FIFO content without popping it, introduce the fifo8_peek_buf() method by factoring common content from fifo8_pop_buf(). Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231109192814.95977-3-philmd@linaro.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2024-01-10util/fifo8: Allow fifo8_pop_buf() to not populate popped lengthPhilippe Mathieu-Daudé2-9/+13
There might be cases where we know the number of bytes we can pop from the FIFO, or we simply don't care how many bytes is returned. Allow fifo8_pop_buf() to take a NULL numptr. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231109192814.95977-2-philmd@linaro.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2024-01-09target/arm: Add FEAT_NV2 to max, neoverse-n2, neoverse-v1 CPUsPeter Maydell3-6/+2
Enable FEAT_NV2 on the 'max' CPU, and stop filtering it out for the Neoverse N2 and Neoverse V1 CPUs. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Enhance CPU_LOG_INT to show SPSR on AArch64 exception-entryPeter Maydell1-0/+1
We already print various lines of information when we take an exception, including the ELR and (if relevant) the FAR. Now that FEAT_NV means that we might report something other than the old PSTATE to the guest as the SPSR, it's worth logging this as well. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Report HCR_EL2.{NV,NV1,NV2} in cpu dumpsPeter Maydell1-0/+5
When interpreting CPU dumps where FEAT_NV and FEAT_NV2 are in use, it's helpful to include the values of HCR_EL2.{NV,NV1,NV2} in the CPU dump format, as a way of distinguishing when we are in EL1 as part of executing guest-EL2 and when we are just in normal EL1. Add the bits to the end of the log line that shows PSTATE and similar information: PSTATE=000003c9 ---- EL2h BTYPE=0 NV NV2 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09hw/intc/arm_gicv3_cpuif: Mark up VNCR offsets for GIC CPU registersPeter Maydell1-0/+11
Mark up the cpreginfo structs for the GIC CPU registers to indicate the offsets from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Mark up VNCR offsets (offsets >= 0x200, except GIC)Peter Maydell1-0/+8
Mark up the cpreginfo structs to indicate offsets for system registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. This covers all the remaining offsets at 0x200 and above, except for the GIC ICH_* registers. (Note that because we don't implement FEAT_SPE, FEAT_TRF, FEAT_MPAM, FEAT_BRBE or FEAT_AMUv1p1 we don't implement any of the registers that use offsets at 0x800 and above.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Mark up VNCR offsets (offsets 0x168..0x1f8)Peter Maydell1-0/+18
Mark up the cpreginfo structs to indicate offsets for system registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. This commit covers offsets 0x168 to 0x1f8. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Mark up VNCR offsets (offsets 0x100..0x160)Peter Maydell2-0/+23
Mark up the cpreginfo structs to indicate offsets for system registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. This commit covers offsets 0x100 to 0x160. Many (but not all) of the registers in this range have _EL12 aliases, and the slot in memory is shared between the _EL12 version of the register and the _EL1 version. Where we programmatically generate the regdef for the _EL12 register, arrange that its nv2_redirect_offset is set up correctly to do this. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Mark up VNCR offsets (offsets 0x0..0xff)Peter Maydell1-0/+12
Mark up the cpreginfo structs to indicate offsets for system registers from VNCR_EL2, as defined in table D8-66 in rule R_CSRPQ in the Arm ARM. This commit covers offsets below 0x100; all of these registers are redirected to memory regardless of the value of HCR_EL2.NV1. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Report VNCR_EL2 based faults correctlyPeter Maydell4-8/+47
If FEAT_NV2 redirects a system register access to a memory offset from VNCR_EL2, that access might fault. In this case we need to report the correct syndrome information: * Data Abort, from same-EL * no ISS information * the VNCR bit (bit 13) is set and the exception must be taken to EL2. Save an appropriate syndrome template when generating code; we can then use that to: * select the right target EL * reconstitute a correct final syndrome for the data abort * report the right syndrome if we take a FEAT_RME granule protection fault on the VNCR-based write Note that because VNCR is bit 13, we must start keeping bit 13 in template syndromes, by adjusting ARM_INSN_START_WORD2_SHIFT. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Implement FEAT_NV2 redirection of sysregs to RAMPeter Maydell5-0/+84
FEAT_NV2 requires that when HCR_EL2.{NV,NV2} == 0b11 then accesses by EL1 to certain system registers are redirected to RAM. The full list of affected registers is in the table in rule R_CSRPQ in the Arm ARM. The registers may be normally accessible at EL1 (like ACTLR_EL1), or normally UNDEF at EL1 (like HCR_EL2). Some registers redirect to RAM only when HCR_EL2.NV1 is 0, and some only when HCR_EL2.NV1 is 1; others trap in both cases. Add the infrastructure for identifying which registers should be redirected and turning them into memory accesses. This code does not set the correct syndrome or arrange for the exception to be taken to the correct target EL if the access via VNCR_EL2 faults; we will do that in the next commit. Subsequent commits will mark up the relevant regdefs to set their nv2_redirect_offset, and if relevant one of the two flags which indicates that the redirect happens only for a particular value of HCR_EL2.NV1. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2024-01-09target/arm: Handle FEAT_NV2 redirection of SPSR_EL2, ELR_EL2, ESR_EL2, FAR_EL2Peter Maydell6-5/+58
Under FEAT_NV2, when HCR_EL2.{NV,NV2} == 0b11 at EL1, accesses to the registers SPSR_EL2, ELR_EL2, ESR_EL2, FAR_EL2 and TFSR_EL2 (which would UNDEF without FEAT_NV or FEAT_NV2) should instead access the equivalent EL1 registers SPSR_EL1, ELR_EL1, ESR_EL1, FAR_EL1 and TFSR_EL1. Because there are only five registers involved and the encoding for the EL1 register is identical to that of the EL2 register except that opc1 is 0, we handle this by finding the EL1 register in the hash table and using it instead. Note that traps that apply to direct accesses to the EL1 register, such as active fine-grained traps or other trap bits, do not trigger when it is accessed via the EL2 encoding in this way. However, some traps that are defined by the EL2 register may apply. We therefore call the EL2 register's accessfn first. The only one of the five which has such traps is TFSR_EL2: make sure its accessfn correctly handles both FEAT_NV (where we trap to EL2 without checking ATA bits) and FEAT_NV2 (where we check ATA bits and then redirect to TFSR_EL1). (We don't need the NV1 tbflag bit until the next patch, but we introduce it here to avoid putting the NV, NV1, NV2 bits in an odd order.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Handle FEAT_NV2 changes to when SPSR_EL1.M reports EL2Peter Maydell1-4/+12
With FEAT_NV2, the condition for when SPSR_EL1.M should report that an exception was taken from EL2 changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Implement VNCR_EL2 registerPeter Maydell2-0/+29
For FEAT_NV2, a new system register VNCR_EL2 holds the base address of the memory which nested-guest system register accesses are redirected to. Implement this register. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Handle HCR_EL2 accesses for FEAT_NV2 bitsPeter Maydell2-0/+8
FEAT_NV2 defines another new bit in HCR_EL2: NV2. When the feature is enabled, allow this bit to be written in HCR_EL2. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Add FEAT_NV to max, neoverse-n2, neoverse-v1 CPUsPeter Maydell3-3/+7
Enable FEAT_NV on the 'max' CPU, and stop filtering it out for the Neoverse N2 and Neoverse V1 CPUs. We continue to downgrade FEAT_NV2 support to FEAT_NV for the latter two CPU types. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Handle FEAT_NV page table attribute changesPeter Maydell1-0/+21
FEAT_NV requires that when HCR_EL2.{NV,NV1} == {1,1} the handling of some of the page table attribute bits changes for the EL1&0 translation regime: * for block and page descriptors: - bit [54] holds PXN, not UXN - bit [53] is RES0, and the effective value of UXN is 0 - bit [6], AP[1], is treated as 0 * for table descriptors, when hierarchical permissions are enabled: - bit [60] holds PXNTable, not UXNTable - bit [59] is RES0 - bit [61], APTable[0] is treated as 0 Implement these changes to the page table attribute handling. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Treat LDTR* and STTR* as LDR/STR when NV, NV1 is 1, 1Peter Maydell1-2/+4
FEAT_NV requires (per I_JKLJK) that when HCR_EL2.{NV,NV1} is {1,1} the unprivileged-access instructions LDTR, STTR etc behave as normal loads and stores. Implement the check that handles this. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Don't honour PSTATE.PAN when HCR_EL2.{NV, NV1} == {1, 1}Peter Maydell1-0/+3
For FEAT_NV, when HCR_EL2.{NV,NV1} is {1,1} PAN is always disabled even when the PSTATE.PAN bit is set. Implement this by having arm_pan_enabled() return false in this situation. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Always use arm_pan_enabled() when checking if PAN is enabledPeter Maydell1-11/+11
Currently the code in target/arm/helper.c mostly checks the PAN bits in env->pstate or env->uncached_cpsr directly when it wants to know if PAN is enabled, because in most callsites we know whether we are in AArch64 or AArch32. We do have an arm_pan_enabled() function, but we only use it in a few places where the code might run in either an AArch32 or AArch64 context. For FEAT_NV, when HCR_EL2.{NV,NV1} is {1,1} PAN is always disabled even when the PSTATE.PAN bit is set, the "is PAN enabled" test becomes more complicated. Make all places that check for PAN use arm_pan_enabled(), so we have a place to put the FEAT_NV test. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Trap registers when HCR_EL2.{NV, NV1} == {1, 1}Peter Maydell1-4/+41
When HCR_EL2.{NV,NV1} is {1,1} we must trap five extra registers to EL2: VBAR_EL1, ELR_EL1, SPSR_EL1, SCXTNUM_EL1 and TFSR_EL1. Implement these traps. This trap does not apply when FEAT_NV2 is implemented and enabled; include the check that HCR_EL2.NV2 is 0 here, to save us having to come back and add it later. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Set SPSR_EL1.M correctly when nested virt is enabledPeter Maydell1-0/+6
FEAT_NV requires that when HCR_EL2.{NV,NV1} == {1,0} and an exception is taken from EL1 to EL1 then the reported EL in SPSR_EL1.M should be EL2, not EL1. Implement this behaviour. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Make NV reads of CurrentEL return EL2Peter Maydell1-2/+7
FEAT_NV requires that when HCR_EL2.NV is set reads of the CurrentEL register from EL1 always report EL2 rather than the real EL. Implement this. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
2024-01-09target/arm: Trap sysreg accesses for FEAT_NVPeter Maydell5-10/+77
For FEAT_NV, accesses to system registers and instructions from EL1 which would normally UNDEF there but which work in EL2 need to instead be trapped to EL2. Detect this both for "we know this will UNDEF at translate time" and "we found this UNDEFs at runtime", and make the affected registers trap to EL2 instead. The Arm ARM defines the set of registers that should trap in terms of their names; for our implementation this would be both awkward and inefficent as a test, so we instead trap based on the opc1 field of the sysreg. The regularity of the architectural choice of encodings for sysregs means that in practice this captures exactly the correct set of registers. Regardless of how we try to define the registers this trapping applies to, there's going to be a certain possibility of breakage if new architectural features introduce new registers that don't follow the current rules (FEAT_MEC is one example already visible in the released sysreg XML, though not yet in the Arm ARM). This approach seems to me to be straightforward and likely to require a minimum of manual overrides. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com>
generated by cgit v1.1 at 2025-09-27 02:36:59 +0000