summary refs log tree commit diff stats
path: root/rust/qemu-api/src (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-12-20target/riscv: add ssstateenDaniel Henrique Barboza3-1/+11
ssstateen is defined in RVA22 as: "Supervisor-mode view of the state-enable extension. The supervisor-mode (sstateen0-3) and hypervisor-mode (hstateen0-3) state-enable registers must be provided." Add ssstateen as a named feature that is available if we also have smstateen. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20241113171755.978109-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv/tcg: hide warn for named feats when disabling via priv_verDaniel Henrique Barboza1-3/+10
Commit 68c9e54bea handled a situation where a warning was being shown when using the 'sifive_e' cpu when disabling the named extension zic64b. It makes little sense to show user warnings for named extensions that users can't control, and the solution taken was to disable zic64b manually in riscv_cpu_update_named_features(). This solution won't scale well when adding more named features, and can eventually end up repeating riscv_cpu_disable_priv_spec_isa_exts(). Change riscv_cpu_disable_priv_spec_isa_exts() to not show warnings when disabling a named feature. This will accomplish the same thing we're doing today while avoiding having two points where we're disabling exts via priv_ver mismatch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241113171755.978109-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Include missing headers in 'internals.h'Philippe Mathieu-Daudé1-0/+3
Rather than relying on implicit includes, explicit them, in order to avoid when refactoring unrelated headers: target/riscv/internals.h:49:15: error: use of undeclared identifier 'PRV_S' 49 | ret = PRV_S; | ^ target/riscv/internals.h:93:9: error: call to undeclared function 'env_archcpu'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 93 | if (env_archcpu(env)->cfg.ext_zfinx) { | ^ target/riscv/internals.h:101:15: error: unknown type name 'float32'; did you mean 'float'? 101 | static inline float32 check_nanbox_s(CPURISCVState *env, uint64_t f) | ^~~~~~~ | float Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241203200828.47311-3-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Include missing headers in 'vector_internals.h'Philippe Mathieu-Daudé1-0/+1
Rather than relying on implicit includes, explicit them, in order to avoid when refactoring unrelated headers: target/riscv/vector_internals.h:36:12: error: call to undeclared function 'FIELD_EX32'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 36 | return FIELD_EX32(simd_data(desc), VDATA, NF); | ^ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241203200828.47311-2-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Check svukte is not enabled in RV32Fea.Wang1-0/+5
The spec explicitly says svukte doesn't support RV32. So check that it is not enabled in RV32. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-7-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Expose svukte ISA extensionFea.Wang1-0/+2
Add "svukte" in the ISA string when svukte extension is enabled. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-6-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Check memory access to meet svukte ruleFea.Wang1-0/+55
Follow the Svukte spec, do the memory access address checking 1. Include instruction fetches or explicit memory accesses 2. System run in effective privilege U or VU 3. Check senvcfg[UKTE] being set, or hstatus[HUKTE] being set if instruction is HLV, HLVX, HSV and execute from U mode to VU mode 4. Depend on Sv39 and check virtual addresses bit[SXLEN-1] 5. Raises a page-fault exception corresponding to the original access type. Ref: https://github.com/riscv/riscv-isa-manual/pull/1564/files Signed-off-by: Frank Chang <frank.chang@sifive.com> Signed-off-by: Fea.Wang <fea.wang@sifive.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-5-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Support hstatus[HUKTE] bit when svukte extension is enabledFea.Wang2-0/+4
Svukte extension add HUKTE bit, bit[24] in hstatus CSR. The written value will be masked when the svukte extension is not enabled. When hstatus[HUKTE] bit is set, HLV/HLVX/HSV work in the U-mode should do svukte check. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-4-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Support senvcfg[UKTE] bit when svukte extension is enabledFea.Wang2-0/+5
Svukte extension add UKTE bit, bit[8] in senvcfg CSR. The bit will be supported when the svukte extension is enabled. When senvcfg[UKTE] bit is set, the memory access from U-mode should do the svukte check only except HLV/HLVX/HSV H-mode instructions which depend on hstatus[HUKTE]. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-3-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Add svukte extension capability variableFea.Wang1-0/+1
Refer to the draft of svukte extension from: https://github.com/riscv/riscv-isa-manual/pull/1564 Svukte provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supervisor software's address-space layout. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241203034932.25185-2-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv: Add the checking if DTB overlaps to kernel or initrdJim Shu2-1/+27
DTB is placed to the end of memory, so we will check if the start address of DTB overlaps to the address of kernel/initrd. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241120153935.24706-4-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv: Add a new struct RISCVBootInfoJim Shu8-56/+90
Add a new struct RISCVBootInfo to sync boot information between multiple boot functions. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241120153935.24706-3-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv: Support to load DTB after 3GB memory on 64-bit system.Jim Shu6-14/+20
Larger initrd image will overlap the DTB at 3GB address. Since 64-bit system doesn't have 32-bit addressable issue, we just load DTB to the end of dram in 64-bit system. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241120153935.24706-2-jim.shu@sifive.com> [ Changes by AF - Store fdt_load_addr_hi32 in the reset vector ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/char/riscv_htif: Clarify MemoryRegionOps expect 32-bit accessesPhilippe Mathieu-Daudé1-0/+4
Looking at htif_mm_ops[] read/write handlers, we notice they expect 32-bit values to accumulate into to the 'fromhost' and 'tohost' 64-bit variables. Explicit by setting the .impl min/max fields. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241129154304.34946-4-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/char/riscv_htif: Explicit little-endian implementationPhilippe Mathieu-Daudé1-5/+6
Since our RISC-V system emulation is only built for little endian, the HTIF device aims to interface with little endian memory accesses, thus we can explicit htif_mm_ops:endianness being DEVICE_LITTLE_ENDIAN. In that case tswap64() is equivalent to le64_to_cpu(), as in "convert this 64-bit little-endian value into host cpu order". Replace to simplify. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241129154304.34946-3-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20MAINTAINERS: Cover RISC-V HTIF interfacePhilippe Mathieu-Daudé1-0/+2
The HTIF interface is RISC-V specific, add it within the MAINTAINERS section covering hw/riscv/. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241129154304.34946-2-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20tests/qtest/bios-tables-test: Update virt SPCR golden reference for RISC-VSia Jee Heng2-1/+0
Update the virt SPCR golden reference file for RISC-V to accommodate the SPCR Table revision 4 [1], utilizing the iasl binary compiled from the latest ACPICA repository. The SPCR table has been modified to adhere to the revision 4 format [2]. [1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [2]: https://github.com/acpica/acpica/pull/931 Diffs from iasl: /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20200925 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/riscv64/virt/SPCR, Wed Aug 28 18:28:19 2024 + * Disassembly of /tmp/aml-MN0NS2, Wed Aug 28 18:28:19 2024 * * ACPI Data Table [SPCR] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "SPCR" [Serial Port Console Redirection table] -[004h 0004 4] Table Length : 00000050 -[008h 0008 1] Revision : 02 -[009h 0009 1] Checksum : B9 +[004h 0004 4] Table Length : 0000005A +[008h 0008 1] Revision : 04 +[009h 0009 1] Checksum : 13 [00Ah 0010 6] Oem ID : "BOCHS " [010h 0016 8] Oem Table ID : "BXPC " [018h 0024 4] Oem Revision : 00000001 [01Ch 0028 4] Asl Compiler ID : "BXPC" [020h 0032 4] Asl Compiler Revision : 00000001 -[024h 0036 1] Interface Type : 00 +[024h 0036 1] Interface Type : 12 [025h 0037 3] Reserved : 000000 [028h 0040 12] Serial Port Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 20 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 01 [Byte Access:8] [02Ch 0044 8] Address : 0000000010000000 [034h 0052 1] Interrupt Type : 10 [035h 0053 1] PCAT-compatible IRQ : 00 [036h 0054 4] Interrupt : 0000000A [03Ah 0058 1] Baud Rate : 07 [03Bh 0059 1] Parity : 00 [03Ch 0060 1] Stop Bits : 01 [03Dh 0061 1] Flow Control : 00 [03Eh 0062 1] Terminal Type : 00 [04Ch 0076 1] Reserved : 00 [040h 0064 2] PCI Device ID : FFFF [042h 0066 2] PCI Vendor ID : FFFF [044h 0068 1] PCI Bus : 00 [045h 0069 1] PCI Device : 00 [046h 0070 1] PCI Function : 00 [047h 0071 4] PCI Flags : 00000000 [04Bh 0075 1] PCI Segment : 00 -[04Ch 0076 4] Reserved : 00000000 +[04Ch 0076 004h] Uart Clock Freq : 00000000 +[050h 0080 004h] Precise Baud rate : 00000000 +[054h 0084 002h] NameSpaceStringLength : 0002 +[056h 0086 002h] NameSpaceStringOffset : 0058 +[058h 0088 002h] NamespaceString : "." -Raw Table Data: Length 80 (0x50) +Raw Table Data: Length 90 (0x5A) - 0000: 53 50 43 52 50 00 00 00 02 B9 42 4F 43 48 53 20 // SPCRP.....BOCHS + 0000: 53 50 43 52 5A 00 00 00 04 13 42 4F 43 48 53 20 // SPCRZ.....BOCHS 0010: 42 58 50 43 20 20 20 20 01 00 00 00 42 58 50 43 // BXPC ....BXPC - 0020: 01 00 00 00 00 00 00 00 00 20 00 01 00 00 00 10 // ......... ...... + 0020: 01 00 00 00 12 00 00 00 00 20 00 01 00 00 00 10 // ......... ...... 0030: 00 00 00 00 10 00 0A 00 00 00 07 00 01 00 00 03 // ................ 0040: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 // ................ + 0050: 00 00 00 00 02 00 58 00 2E 00 // ......X... Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Message-ID: <20241028015744.624943-4-jeeheng.sia@starfivetech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/acpi: Upgrade ACPI SPCR table to support SPCR table revision 4 formatSia Jee Heng6-13/+42
Update the SPCR table to accommodate the SPCR Table revision 4 [1]. The SPCR table has been modified to adhere to the revision 4 format [2]. [1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [2]: https://github.com/acpica/acpica/pull/931 Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Message-ID: <20241028015744.624943-3-jeeheng.sia@starfivetech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20qtest: allow SPCR acpi table changesSia Jee Heng1-0/+1
Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241028015744.624943-2-jeeheng.sia@starfivetech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv: Add Microblaze V generic boardSai Pavan Boddu6-0/+242
Add a basic board with interrupt controller (intc), timer, serial (uartlite), small memory called LMB@0 (128kB) and DDR@0x80000000 (configured via command line eg. -m 2g). This is basic configuration which matches HW generated out of AMD Vivado (design tools). But initial configuration is going beyond what it is configured by default because validation should be done on other configurations too. That's why wire also additional uart16500, axi ethernet(with axi dma). GPIOs, i2c and qspi is also listed for completeness. IRQ map is: (addr) 0 - timer (0x41c00000) 1 - uartlite (0x40600000) 2 - i2c (0x40800000) 3 - qspi (0x44a00000) 4 - uart16550 (0x44a10000) 5 - emaclite (0x40e00000) 6 - timer2 (0x41c10000) 7 - axi emac (0x40c00000) 8 - axi dma (0x41e00000) 9 - axi dma 10 - gpio (0x40000000) 11 - gpio2 (0x40010000) 12 - gpio3 (0x40020000) Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241125134739.18189-1-sai.pavan.boddu@amd.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20docs: update riscv/virt.rst with kernel-irqchip=split supportDaniel Henrique Barboza3-0/+91
Also add a new page, docs/specs/riscv-aia.rst, where we're documenting the state of AIA support in QEMU w.r.t the controllers being emulated or not depending on the AIA and accelerator settings. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv/kvm: remove irqchip_split() restrictionDaniel Henrique Barboza1-5/+0
Remove the 'irqchip_split()' restriction in kvm_arch_init() now that we have support for "-accel kvm,kernel-irqchip=split". Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/intc/riscv_aplic: add kvm_msicfgaddr for split mode aplic-imsicDaniel Henrique Barboza3-10/+44
The last step to enable KVM AIA aplic-imsic with irqchip in split mode is to deal with how MSIs are going to be sent. In our current design we don't allow an APLIC controller to send MSIs unless it's on m-mode. And we also do not allow Supervisor MSI address configuration via the 'smsiaddrcfg' and 'smsiaddrcfgh' registers unless it's also a m-mode APLIC controller. Add a new RISCVACPLICState attribute called 'kvm_msicfgaddr'. This attribute represents the base configuration address for MSIs, in our case the base addr of the IMSIC controller. This attribute is being set only when running irqchip_split() mode with aia=aplic-imsic. During riscv_aplic_msi_send() we'll check if the attribute was set to skip the check for a m-mode APLIC controller and to change the resulting MSI addr by adding kvm_msicfgaddr right before address_space_stl_le(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/virt.c, riscv_aplic.c: add 'emulated_aplic' helpersDaniel Henrique Barboza3-5/+34
The current logic to determine if we don't need an emulated APLIC controller, i.e. KVM will provide for us, is to determine if we're running KVM, with in-kernel irqchip support, and running aia=aplic-imsic. This is modelled by riscv_is_kvm_aia_aplic_imsic() and virt_use_kvm_aia_aplic_imsic(). This won't suffice to support irqchip_split() mode: it will match exactly the same conditions as the one above, but setting the irqchip to 'split' mode will now require us to emulate an APLIC s-mode controller, like we're doing with 'aia=aplic'. Create a new riscv_use_emulated_aplic() helper that will encapsulate this logic. Replace the uses of "riscv_is_kvm_aia_aplic_imsic()" with this helper every time we're taking a decision on emulate an APLIC controller or not. Do the same in virt.c with virt_use_emulated_aplic(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv/kvm: consider irqchip_split() in aia_create()Daniel Henrique Barboza1-15/+23
Before adding support to kernel-irqchip=split when using KVM AIA we need to change how we create the in-kernel AIA device. In the use case we have so far, i.e. in-kernel irqchip without split mode, both the s-mode APLIC and IMSIC controllers are provided by the irqchip. In irqchip_split() mode we'll emulate the s-mode APLIC controller, which will send MSIs to the in-kernel IMSIC controller. To do that we need to change kvm_riscv_aia_create() to not create the in-kernel s-mode APLIC controller. In the kernel source arch/riscv/kvm/aia_aplic.c, function kvm_riscv_aia_aplic_init(), we verify that the APLIC controller won't be instantiated by KVM if we do not set 'nr_sources', which is set via KVM_DEV_RISCV_AIA_CONFIG_SRCS. For QEMU this means that we should not set 'aia_irq_num' during kvm_riscv_aia_create() in irqchip_split() mode. In this same condition, skip KVM_DEV_RISCV_AIA_ADDR_APLIC as well since it is used to set the base address for the in-kernel APLIC controller. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/virt.c: rename helper to virt_use_kvm_aia_aplic_imsic()Daniel Henrique Barboza1-5/+7
Similar to the riscv_is_kvm_aia_aplic_imsic() helper from riscv_aplic.c, the existing virt_use_kvm_aia() is testing for KVM aia=aplic-imsic with in-kernel irqchip enabled. It is not checking for a generic AIA support. Rename the helper to virt_use_kvm_aia_aplic_imsic() to reflect what the helper is doing, and use the existing riscv_is_kvm_aia_aplic_imsic() to obscure details such as the presence of the in-kernel irqchip. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/virt.c: reduce virt_use_kvm_aia() usageDaniel Henrique Barboza1-6/+4
In create_fdt_sockets() we have the following pattern: if (kvm_enabled() && virt_use_kvm_aia(s)) { (... do stuff ...) } else { (... do other stuff ...) } if (kvm_enabled() && virt_use_kvm_aia(s)) { (... do more stuff ...) } else { (... do more other stuff) } Do everything in a single if/else clause to reduce the usage of virt_use_kvm_aia() helper and to make the code a bit less repetitive. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/intc/riscv_aplic: rename is_kvm_aia()Daniel Henrique Barboza2-4/+5
The helper is_kvm_aia() is checking not only for AIA, but for aplic-imsic (i.e. "aia=aplic-imsic" in 'virt' RISC-V machine) with an in-kernel chip present. Rename it to be a bit clear what the helper is doing since we'll add more AIA helpers in the next patches. Make the helper public because the 'virt' machine will use it as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241119191706.718860-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20target/riscv: Add Tenstorrent Ascalon CPUAnton Blanchard2-0/+68
Add a CPU entry for the Tenstorrent Ascalon CPU, a series of 2 wide to 8 wide RV64 cores. More details can be found at https://tenstorrent.com/ip/tt-ascalon Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241113110459.1607299-1-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20docs/specs: add riscv-iommu-sys informationDaniel Henrique Barboza2-3/+37
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/riscv-iommu: implement reset protocolDaniel Henrique Barboza6-2/+82
Add a riscv_iommu_reset() helper in the base emulation code that implements the expected reset behavior as defined by the riscv-iommu spec. Devices can then use this helper in their own reset callbacks. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/virt.c, riscv-iommu-sys.c: add MSIx supportDaniel Henrique Barboza3-5/+119
MSIx support is added in the RISC-V IOMMU platform device by including the required MSIx facilities to alow software to properly setup the MSIx subsystem. We took inspiration of what is being done in the riscv-iommu-pci device, mainly msix_init() and msix_notify(), while keeping in mind that riscv-iommu-sys isn't a true PCI device and we don't need to copy/paste all the contents of these MSIx functions. Two extra MSI MemoryRegions were added: 'msix-table' and 'msix-pba'. They are used to manage r/w of the MSI table and Pending Bit Array (PBA) respectively. Both are subregions of the main IOMMU memory region, iommu->regs_mr, initialized during riscv_iommu_realize(), and each one has their own handlers for MSIx reads and writes. This is the expected memory map when using this device in the 'virt' machine: 0000000003010000-0000000003010fff (prio 0, i/o): riscv-iommu-regs 0000000003010300-000000000301034f (prio 0, i/o): msix-table 0000000003010400-0000000003010407 (prio 0, i/o): msix-pba We're now able to set IGS to RISCV_IOMMU_CAP_IGS_BOTH, and userspace is free to decide which interrupt model to use. Enabling MSIx support for this device in the 'virt' machine requires adding 'msi-parent' in the iommu-sys DT. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-6-dbarboza@ventanamicro.com> [ Changes by AF: - Used PRIx64 in trace ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/virt: Add IOMMU as platform device if the option is setSunil V L3-3/+109
Add a new machine option called 'iommu-sys' that enables a riscv-iommu-sys platform device for the 'virt' machine. The option is default 'off'. The device will use IRQs 36 to 39. We will not support both riscv-iommu-sys and riscv-iommu-pci devices in the same board in this first implementation. If a riscv-iommu-pci device is added in the command line we will disable the riscv-iommu-sys device. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv: add riscv-iommu-sys platform deviceTomasz Jeznach4-3/+134
This device models the RISC-V IOMMU as a sysbus device. The same design decisions taken in the riscv-iommu-pci device were kept, namely the existence of 4 vectors are available for each interrupt cause. The WSIs are emitted using the input of the s->notify() callback as a index to an IRQ list. The IRQ list starts at 'base_irq' and goes until base_irq + 3. This means that boards must have 4 contiguous IRQ lines available, starting from 'base_irq'. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/riscv-iommu: parametrize CAP.IGSDaniel Henrique Barboza4-0/+16
Interrupt Generation Support (IGS) is a capability that is tied to the interrupt deliver mechanism, not with the core IOMMU emulation. We should allow device implementations to set IGS as they wish. A new helper is added to make it easier for device impls to set IGS. Use it in our existing IOMMU device (riscv-iommu-pci) to set RISCV_IOMMU_CAPS_IGS_MSI. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/riscv-iommu.c: add riscv_iommu_instance_init()Daniel Henrique Barboza1-32/+39
Move all the static initializion of the device to an init() function, leaving only the dynamic initialization to be done during realize. With this change s->cap is initialized with RISCV_IOMMU_CAP_DBG during init(), and realize() will increment s->cap with the extra caps. This will allow callers to add IOMMU capabilities before the realization. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241106133407.604587-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/intc/riscv_aplic: Fix APLIC in_clrip and clripnum write emulationYong-Xuan Wang1-1/+5
In the section "4.7 Precise effects on interrupt-pending bits" of the RISC-V AIA specification defines that: "If the source mode is Level1 or Level0 and the interrupt domain is configured in MSI delivery mode (domaincfg.DM = 1): The pending bit is cleared whenever the rectified input value is low, when the interrupt is forwarded by MSI, or by a relevant write to an in_clrip register or to clripnum." Update the riscv_aplic_set_pending() to match the spec. Fixes: bf31cf06eb ("hw/intc/riscv_aplic: Fix setipnum_le write emulation for APLIC MSI-mode") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20241029085349.30412-1-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-20hw/riscv/riscv-iommu.c: Correct the validness check of iovaJason Chien1-3/+20
From RISCV IOMMU spec section 2.1.3: When SXL is 1, the following rules apply: - If the first-stage is not Bare, then a page fault corresponding to the original access type occurs if the IOVA has bits beyond bit 31 set to 1. - If the second-stage is not Bare, then a guest page fault corresponding to the original access type occurs if the incoming GPA has bits beyond bit 33 set to 1. From RISCV IOMMU spec section 2.3 step 17: Use the process specified in Section "Two-Stage Address Translation" of the RISC-V Privileged specification to determine the GPA accessed by the transaction. From RISCV IOMMU spec section 2.3 step 19: Use the second-stage address translation process specified in Section "Two-Stage Address Translation" of the RISC-V Privileged specification to translate the GPA A to determine the SPA accessed by the transaction. This commit adds the iova check with the following rules: - For Sv32, Sv32x4, Sv39x4, Sv48x4 and Sv57x4, the iova must be zero extended. - For Sv39, Sv48 and Sv57, the iova must be signed extended with most significant bit. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20241114065617.25133-1-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-12-18qga: Don't access global variable in run_agent_once()Michal Privoznik1-1/+1
The run_agent_once() function is already given GAState via an argument. There's no need to access the global ga_state variable which points to the argument anyways (thanks to initialize_agent()). Worse, some parts of the function use the argument and the other use the global variable. Stick with the function argument. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Link: https://lore.kernel.org/r/8ae7f5d5032b14a5b956fe8aaf47bae5ca401699.1733414906.git.mprivozn@redhat.com Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
2024-12-18qemu-ga-win: Fix a typo errorDehan Meng1-1/+1
There is a typo error for api 'guest-get-osinfo', the win2025's version in WIN_10_0_SERVER_VERSION_MATRIX should be adjusted. Signed-off-by: Dehan Meng <demeng@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Link: https://lore.kernel.org/r/20241210054616.260386-1-demeng@redhat.com Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
2024-12-18qga: skip bind mounts in fs listJean-Louis Dupond1-0/+25
The filesystem list in build_fs_mount_list should skip bind mounts. This because we end up in locking situations when doing fsFreeze. Like mentioned in [1] and [2]. Next to that, the build_fs_mount_list call did a fallback via build_fs_mount_list_from_mtab if mountinfo did not exist. There it skipped bind mounts, but this is broken for newer OS. This as mounts does not return the path of the bind mount but the underlying dev/partition, so S_ISDIR will never return true in dev_major_minor call. This patch simply checks the existing devmajor:devminor tuple in the mounts, and if it already exists, this means we have the same devices mounted again, a bind mount. So skip this. Same approach is used in open-vm-tools [3]. [1]: https://gitlab.com/qemu-project/qemu/-/issues/592 [2]: https://gitlab.com/qemu-project/qemu/-/issues/520 [3]: https://github.com/vmware/open-vm-tools/commit/d58847b497e212737007958c945af1df22a8ab58 Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be> Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com> Link: https://lore.kernel.org/r/20241002100634.162499-2-jean-louis@dupond.be Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
2024-12-18meson.build: Disallow libnfs v6 to fix the broken macOS buildThomas Huth1-1/+1
The macOS builds in our CI (and possibly other very recent distros) are currently broken since the update to libnfs version 6 there. That version apparently comes with a big API breakage. v5.0.3 was the final release of the old API (see the libnfs commit here: https://github.com/sahlberg/libnfs/commit/4379837 ). Disallow version 6.x for now to get the broken CI job working again. Once somebody had enough time to adapt our code in block/nfs.c, we can revert this change again. Message-ID: <20241218065157.209020-1-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: Convert the hotplug_cpu avocado testThomas Huth3-37/+70
Since we don't have ssh support in the functional test framework yet, simply use the serial console for this test instead. It's also sufficient to only boot into an initrd here, no need to fire up a full-blown guest, so the test now finishes much faster. While we're at it, also unplug the CPU now and check that it is gone in the guest. Message-ID: <20241217142020.155776-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: Convert the intel_iommu avocado testThomas Huth4-123/+179
Convert the intel_iommu test to the new functional framework. This test needs some changes since we neither support the old 'LinuxTest' class in the functional framework yet, nor a way to use SSH for running commands in the guest. So we now directly download a Fedora kernel and initrd and set up the serial console for executing the commands and for looking for the results. Instead of configuring the cloud image via cloud-init, we now simply mount the file system manually from an initrd rescue shell. While the old test was exercising the network with a "dnf install" command (which is not the best option for the CI since this depends on third party servers), the new code is now setting up a little HTTP server in the guest and transfers a file from the guest to the host instead. The test should now run much faster and more reliable (since we don't depend on the third party servers for "dnf install" anymore), so we can also drop the @skipUnless decorator now. Message-ID: <20241217121550.141072-3-thuth@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: Add a helper function for retrieving the hostfwd portThomas Huth2-5/+10
It's just a wrapper around get_info_usernet_hostfwd_port from the qemu module that is also calling the right monitor command for retrieving the information from QEMU. Message-ID: <20241217121550.141072-2-thuth@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: Convert the arm virt avocado testThomas Huth3-21/+31
Straight forward conversion, basically just the hashsums needed to be updated to sha256 now. Message-ID: <20241206102358.1186644-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: Convert the quanta-gsj avocado testThomas Huth4-86/+97
Straight forward conversion, basically just the hashsums needed to be updated to sha256 now. Message-ID: <20241206102358.1186644-6-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17MAINTAINERS: add myself as reviewer for functional test suiteDaniel P. Berrangé1-0/+1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20241217155953.3950506-33-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: ignore errors when caching assets, except for 404Daniel P. Berrangé1-1/+13
We see periodic errors caching assets due to a combination of transient networking and server problems. With the previous patch to skip running a test when it has missing assets, we can now treat most cache download errors as non-fatal. Only HTTP 404 is retained as fatal, since it is a strong indicator of a fully broken test rather than a transient error. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20241217155953.3950506-32-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-12-17tests/functional: skip tests if assets are not availableDaniel P. Berrangé2-1/+18
If downloading of assets has been disabled, then skip running a test if the assets it has registered are not already downloaded. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20241217155953.3950506-31-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>