summary refs log tree commit diff stats
path: root/rust/qemu-api-macros/src/lib.rs (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-19rust: pl011: simplify handling of the FIFO enabled bit in LCRPaolo Bonzini2-10/+2
Use ==/!= instead of going through bool and xor. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: fix migration streamPaolo Bonzini3-33/+37
The Rust vmstate macros lack the type-safety of their C equivalents (so safe, much abstraction), and therefore they were predictably wrong. The registers have already been changed to 32-bits in the previous patch, but read_pos/read_count/read_trigger also have to be u32 instead of usize. The easiest way to do so is to let the FIFO use u32 indices instead of usize. My plan for making VMStateField typesafe is to have a trait to retrieve a basic VMStateField; for example something like vmstate_uint32 would become an implementation of the VMState trait on u32. Then you'd write something like "vmstate_of!(Type, field).with_version_id(2)". That is, vmstate_of retrieves the basic VMStateField and fills in the offset, and then more changes can be applied on top. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: extend registers to 32 bitsPaolo Bonzini2-33/+26
The PL011 Technical Reference Manual lists the "real" size of the registers in table 3-1, and only rounds up to the next byte when describing the registers; for example, UARTDR is listed as having width 12/8 (12 bits read, 8 written) and only bits 15:0 are listed in "Table 3-2 UARTDR Register". However, in practice these are 32-bit registers, accessible only through 32-bit MMIO accesses; preserving the fiction that they're smaller introduces multiple casts (to go from the bilge bitfield type to e.g u16 to u64) and more importantly it breaks the migration stream because the Rust vmstate macros are not yet type safe. So, just make everything 32-bits wide. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: fix break errors and definition of Data structPaolo Bonzini2-20/+36
The Data struct is wrong, and does not show how bits 8-15 of DR are the receive status. Fix it, and use it to fix break errors ("c >> 8" in the C code does not translate to "c.to_be_bytes()[3]"). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: always use reset() method on registersPaolo Bonzini2-15/+21
For CR, the ugly-ish "0.into()" idiom is already hidden within the reset method. Do not repeat it. For FR, standardize on reset() being equivalent to "*self = Self::default()" and let reset_fifo toggle only the bits that are related to FIFOs. This commit also reproduces C commit 02b1f7f6192 ("hw/char/pl011: Split RX/TX path of pl011_reset_fifo()", 2024-09-13). Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: match break logic of C versionPaolo Bonzini1-2/+1
Check loopback_enabled(), not fifo_enabled(), like the C code. Also, set_break_error() must not happen until the break is read from the FIFO. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: pl011: fix declaration of LineControl bitsPaolo Bonzini1-41/+41
The bits in the LineControl struct were backwards. :( Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19target/i386: Reset TSCs of parked vCPUs too on VM resetMaciej S. Szmigiero5-0/+36
Since commit 5286c3662294 ("target/i386: properly reset TSC on reset") QEMU writes the special value of "1" to each online vCPU TSC on VM reset to reset it. However parked vCPUs don't get that handling and due to that their TSCs get desynchronized when the VM gets reset. This in turn causes KVM to turn off PVCLOCK_TSC_STABLE_BIT in its exported PV clock. Note that KVM has no understanding of vCPU being currently parked. Without PVCLOCK_TSC_STABLE_BIT the sched clock is marked unstable in the guest's kvm_sched_clock_init(). This causes a performance regressions to show in some tests. Fix this issue by writing the special value of "1" also to TSCs of parked vCPUs on VM reset. Reproducing the issue: 1) Boot a VM with "-smp 2,maxcpus=3" or similar 2) device_add host-x86_64-cpu,id=vcpu,node-id=0,socket-id=0,core-id=2,thread-id=0 3) Wait a few seconds 4) device_del vcpu 5) Inside the VM run: # echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable Observe the sched_clock_stable() value is 1. 6) Reboot the VM 7) Once the VM boots once again run inside it: # echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable Observe the sched_clock_stable() value is now 0. Fixes: 5286c3662294 ("target/i386: properly reset TSC on reset") Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/r/5a605a88e9a231386dc803c60f5fed9b48108139.1734014926.git.maciej.szmigiero@oracle.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19kvm: consistently return 0/-errno from kvm_convert_memoryPaolo Bonzini1-4/+4
In case of incorrect parameters, kvm_convert_memory() was returning -1 instead of -EINVAL. The guest won't notice because it will move anyway to RUN_STATE_INTERNAL_ERROR, but fix this for consistency and clarity. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: qemu-api: add a module to wrap functions and zero-sized closuresPaolo Bonzini3-0/+146
One recurring issue when writing Rust bindings is how to convert a Rust function ("fn" or "impl Fn") to a C function, and how to pass around "self" to a C function that only takes a void*. An easy solution would be to store on the heap a pair consisting of a pointer to the Rust function and the pointer to "self", but it is possible to do better. If an "Fn" has zero size (that is, if it is a zero-capture closures or a function pointer---which in turn includes all methods), it is possible to build a generic Rust function that calls it even if you only have the type; you don't need either the pointer to the function itself (because the address of the code is part of the type) or any closure data (because it has size zero). Introduce a wrapper that provides the functionality of calling the function given only its type. Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: qom: add initial subset of methods on ObjectPaolo Bonzini3-3/+66
Add an example of implementing instance methods and converting the result back to a Rust type. In this case the returned types are a string (actually a Cow<str>; but that's transparent as long as it derefs to &str) and a QOM class. Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-19rust: qom: add casting functionalityPaolo Bonzini7-13/+366
Add traits that let client cast typecast safely between object types. In particular, an upcast is compile-time guaranteed to succeed, and a YOLO C-style downcast must be marked as unsafe. The traits are based on an IsA<> trait that declares what is a subclass of what, which is an idea taken from glib-rs (https://docs.rs/glib/latest/glib/object/trait.IsA.html). The four primitives are also taken from there (https://docs.rs/glib/latest/glib/object/trait.Cast.html). However, the implementation of casting itself is a bit different and uses the Deref trait. This removes some pointer arithmetic from the pl011 device; it is also a prerequisite for the definition of methods, so that they can be invoked on all subclass structs. This will use the IsA<> trait to detect the structs that support the methods. glib also has a "monadic" casting trait which could be implemented on Option (as in https://docs.rs/glib/latest/glib/object/trait.CastNone.html) and perhaps even Result. For now I'm leaving it out, as the patch is already big enough and the benefit seems debatable. Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>