Nicolin Chen [Tue, 9 Jun 2026 11:25:42 +0000 (12:25 +0100)]
hw/arm/tegra241-cmdqv: Use mmap'd host VINTF page0 for virtual VINTF page0
Install the mmap'd host VINTF page0 as a RAM-device MemoryRegion
backing the guest's virtual VINTF Page 0 aperture (guest MMIO offset
0x30000) when VINTF is enabled, and remove it on VINTF disable or
reset. This eliminates QEMU trapping for hot-path CONS/PROD index
updates via that aperture.
After this patch, the two VCMDQ Page 0 apertures use different
access paths: the direct aperture (0x10000) remains QEMU-trapped,
while the VINTF aperture (0x30000) is a guest-direct RAM mapping.
The direct aperture is intentionally kept trapped (not aliased to
the host VINTF mmap) so that writes to an unallocated VCMDQ remain
well-defined. The CMDQV architecture allows software to program a
VCMDQ through the direct aperture without first allocating it to a
VINTF; aliasing would route those writes to unallocated logical
slots in the VINTF page, where the hardware silently drops them.
memory: Allow RAM device regions to skip IOMMU mapping
Some RAM device regions created with memory_region_init_ram_device_ptr()
are not intended to be P2P DMA targets.
The VFIO listener currently treats all RAM device regions as DMA
capable and attempts to map them into the IOMMU. For regions without
dma-buf backing this fails and prints warnings such as:
IOMMU_IOAS_MAP failed: Bad address, PCI BAR?
Introduce a MemoryRegion flag (ram_device_skip_iommu_map) to mark RAM
device regions that should not be IOMMU mapped, paired with
memory_region_skip_iommu_map() / memory_region_set_skip_iommu_map()
accessors. When the flag is set, the VFIO listener skips DMA mapping
for that region.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Message-id: 20260609112552.378999-21-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/arm/tegra241-cmdqv: Route allocated VCMDQ Page0 accesses to the mmap'd host VINTF page0
Introduce tegra241_cmdqv_vintf_lvcmdq_ptr() to route VCMDQ Page 0
register accesses through the mmap'd host VINTF Page 0 backing once a
hardware queue has been allocated for the VCMDQ.
The two QEMU-trapped Page 0 apertures (direct at 0x10000, VINTF at
0x30000) are hardware aliases of the same underlying registers. A
subsequent patch installs the VINTF aperture as a RAM-device into
guest MMIO; in this patch both remain QEMU-trapped.
The direct VCMDQ aperture stays QEMU-trapped (rather than aliased
to the VINTF mmap) so that writes to an unallocated VCMDQ remain
well-defined. The CMDQV architecture allows software to program a
VCMDQ through the direct aperture without first allocating it to a
VINTF; aliasing to the VINTF mmap would route those writes into
unallocated logical slots where the hardware silently drops them.
A VCMDQ Page 0 access is served from one of two sources:
- Cache-backed: no hw_queue is allocated for the VCMDQ
(HW_QUEUE_ALLOC has not yet succeeded). Both apertures use
QEMU's register cache.
- HW-backed: HW_QUEUE_ALLOC has succeeded. Both apertures access
the registers directly through the mmap'd host VINTF Page 0.
tegra241_cmdqv_sync_vcmdq() copies any cached writes (CONS_INDX,
PROD_INDX, CONFIG, GERRORN) into the mmap'd page on the cache-to-HW
transition so the guest's earlier register state survives. Freeing a
VCMDQ clears the cached Page0 registers.
Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Message-id: 20260609112552.378999-20-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nicolin Chen [Tue, 9 Jun 2026 11:25:39 +0000 (12:25 +0100)]
hw/arm/tegra241-cmdqv: Allocate HW VCMDQs once configured
Add support for allocating IOMMUFD hardware queues when the guest
programs the VCMDQ BASE registers.
VCMDQ_EN lives in VCMDQ_CONFIG, which is on the VINTF Page0 region
that a later patch installs into guest MMIO — so QEMU won't trap its
writes. Allocate the hardware queue instead once all of these are
set: BASE programmed, CMDQ_ALLOC_MAP.ALLOC, and CMDQV / VINTF
enabled. Each precondition write retries the allocation, so the
guest may program them in any order.
iommufd_backend_alloc_hw_queue() needs the guest physical address of
the VCMDQ ring buffer, so allocation is deferred until the guest has
populated BASE.
If a hardware queue was previously allocated for the same VCMDQ,
free it before reallocation. All allocated VCMDQs are freed when
CMDQV or VINTF is disabled, when the ALLOC bit is cleared, or on reset.
On allocation failure, set CMDQ_INIT_ERR and clear CMDQ_EN_OK in the
cache so trapped guest reads see the failure rather than a queue
that looks live. Clear them on a later successful allocation. A guest
CMDQ_EN write then sets CMDQ_EN_OK only if CMDQ_INIT_ERR is clear.
This is the write side counterpart of the VCMDQ read emulation. Add
write handling for both the direct VCMDQ aperture and the VINTF
logical aperture using the same index decoding and VINTF-to-VCMDQ
translation logic as the read path.
VINTF aperture writes are translated to their direct-aperture
equivalent and update the same cached state. Page 1 registers
(BASE, CONS_INDX_BASE) always update the cache.
Per the CMDQV architecture, a VCMDQ must be allocated to a Virtual
Interface before it is used to send commands to the SMMU. Until
that allocation happens, MMIO writes only update cached register
state - no command consumption, error handling, or interrupt
activity is driven from these writes. Subsequent patches wire up
IOMMU_HW_QUEUE_ALLOC, mmap the host VINTF Page 0, and install it
into guest MMIO; after that, Page 0 writes from either aperture
reach the hardware-backed mmap'd page instead of just the cache.
The direct aperture Page 0 is programmable at any time so long as
CMDQV_EN is enabled. The VINTF (logical) aperture Page 0 is
programmable only once SW has mapped a VCMDQ to a VINTF; the
"logical" view is local to that VINTF.
Add read emulation for both apertures, backed by a single per-VCMDQ
register cache. VINTF aperture reads are translated to their
equivalent direct-aperture offset and served from the same cached
state.
Per the CMDQV architecture, a VCMDQ must be allocated to a Virtual
Interface before it is used to send commands to the SMMU. Until that
allocation happens, reads return cached register state with no HW
interaction. Subsequent patches wire up IOMMU_HW_QUEUE_ALLOC, mmap
the host VINTF Page 0, and install it into guest MMIO; after that,
Page 0 reads from either aperture are served from the hardware-backed
mmap'd page instead of the cache. Page 1 is also a hardware alias,
but the kernel only exposes mmap for Page 0, so Page 1 reads always
trap to QEMU and are served from cache.
Nicolin Chen [Tue, 9 Jun 2026 11:25:36 +0000 (12:25 +0100)]
hw/arm/tegra241-cmdqv: Emulate CMDQ-V Config region
Tegra241 CMDQV exposes control and status registers in the CMDQ-V
Config page (offset [0x0, 0x10000)) used to configure virtual command
queue allocation and interrupt behavior.
Add read/write emulation for the CMDQ-V Config region
([CMDQV_BASE, CMDQV_CMDQ_BASE]), backed by a simple register cache.
This includes CONFIG, PARAM, STATUS, VI error and interrupt maps, CMDQ
allocation map and the VINTF0 related registers defined in the CMDQ-V
Config space. Only VINTF0 is supported; VINTF1-63 are not.
Dispatch writes on access size: Introduced writel_mmio for 4-byte and
writell_mmio for 8-byte. Reads need no split as the MMIO framework masks
the returned value to the access size.
Nicolin Chen [Tue, 9 Jun 2026 11:25:35 +0000 (12:25 +0100)]
hw/arm/tegra241-cmdqv: mmap host VINTF Page0 for CMDQV
The kernel currently exposes a single VINTF per emulated SMMUv3
instance. IOMMU_VIOMMU_ALLOC returns an mmap offset for the host
VINTF Page0 allocated for this SMMU. However, VCMDQs only become
bound to that VINTF after IOMMU_HW_QUEUE_ALLOC, so until then the
mapped Page0 does not back any real VCMDQ state.
mmap the host VINTF Page0 right after IOMMU_VIOMMU_ALLOC, as the host
VINTF is already enabled at that point, and unmap it when the vIOMMU is
freed. The mapping shares the vIOMMU's lifetime. This prepares the VINTF
mapping in advance of subsequent patches that add VCMDQ allocation.
hw/arm/virt: Link SMMUv3 CMDQV resources to platform bus
SMMUv3 devices with acceleration may enable CMDQV extensions
after device realize. In that case, additional MMIO regions and
IRQ lines may be registered but not yet mapped to the platform bus.
Ensure SMMUv3 device resources are linked to the platform bus
during machine_done().
This is safe to do unconditionally since the platform bus helpers
skip resources that are already mapped.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-13-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nicolin Chen [Tue, 9 Jun 2026 11:25:32 +0000 (12:25 +0100)]
hw/arm/tegra241-cmdqv: Implement CMDQV init
Tegra241 CMDQV extends SMMUv3 with support for virtual command queues
(VCMDQs) exposed via a CMDQV MMIO region. The CMDQV MMIO space is split
into 64KB pages:
This patch wires up the Tegra241 CMDQV init callback and allocates
vendor-specific CMDQV state. The state pointer is stored in
SMMUv3AccelState for use by subsequent CMDQV operations.
The CMDQV MMIO region and a dedicated IRQ line are registered with the
SMMUv3 device. The MMIO read/write handlers are currently stubs and will
be implemented in later patches.
The CMDQV interrupt is edge-triggered and indicates VCMDQ or VINTF
error conditions. This patch only registers the IRQ line. Interrupt
generation and propagation to the guest will be added in a subsequent
patch.
hw/arm/tegra241-cmdqv: Probe host Tegra241 CMDQV support
Use IOMMU_GET_HW_INFO to query host support for Tegra241 CMDQV.
Validate the returned data type, version, and minimum number of vCMDQs and
SIDs per Tegra241 CMDQ Virtual Interface(VI). Fail the probe if the host
does not meet these requirements.
The QEMU model supports one Virtual Interface(VI) per VM with 2 vCMDQs and
16 SIDs per VI, so the probe ensures the host implementation is compatible
with these limits.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-11-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/arm/virt: Use stored SMMUv3 device list for IORT build
Introduce a GPtrArray in VirtMachineState to track all SMMUv3 devices
created on the virt machine, and use it when building the IORT table
instead of relying on object_child_foreach_recursive() walks of the
object tree.
This avoids recursive object traversal and provides a foundation for
subsequent patches that need direct access to SMMUv3 instances for
CMDQV-related handling.
No functional change. No bios-tables qtest failures observed.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-10-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/arm/smmuv3-accel: Wire CMDQV ops into accel lifecycle
Add support for selecting and initializing a CMDQV backend based on the
cmdqv OnOffAuto property.
If set to OFF, CMDQV is not used and the default IOMMUFD-backed allocation
path is taken.
If set to AUTO, QEMU attempts to probe a CMDQV backend during device setup.
If probing succeeds, the selected ops are stored in the accelerated SMMUv3
state and used. If probing fails, QEMU silently falls back to the default
path.
If set to ON, QEMU requires CMDQV support. Probing is performed during
setup and failure results in an error.
When a CMDQV backend is active, its callbacks are used for vIOMMU
allocation, free, and reset handling. Otherwise, the base implementation
is used.
The current implementation wires up the Tegra241 CMDQV backend through the
generic ops interface. Functional CMDQV behaviour is added in subsequent
patches.
No functional change.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-9-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Introduce a Tegra241 CMDQV backend that plugs into the SMMUv3 accelerated
CMDQV ops interface.
This patch wires up the Tegra241 CMDQV backend and provides a stub
implementation for CMDQV probe, initialization, vIOMMU allocation
and reset handling.
Functional CMDQV support is added in follow-up patches.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-8-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Command Queue Virtualization (CMDQV) is a hardware extension available
on certain platforms that allows the SMMUv3 command queue to be
virtualized and passed through to a VM, improving performance.
For example, NVIDIA Tegra241 implements CMDQV to support virtualization
of multiple command queues (VCMDQs).
The term CMDQV is used here generically to refer to any platform that
provides hardware support to virtualize the SMMUv3 command queue.
CMDQV support is a specialization of the IOMMUFD-backed accelerated
SMMUv3 path. Introduce an ops interface to factor out CMDQV-specific
probe, initialization, and vIOMMU allocation logic from the base
implementation. The ops pointer and associated state are stored in
the accelerated SMMUv3 state.
This provides an extensible design to support future vendor-specific
CMDQV implementations.
No functional change.
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-7-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
system/iommufd: Remove unused viommu pointer from IOMMUFDVeventq
The viommu field is assigned but never used. Callers freeing the
veventq already have access to the IOMMUFDViommu object through other
references, so this field is redundant.
Removing it also simplifies upcoming changes where veventq is
allocated based on the viommu id before the IOMMUFDViommu object is
created (e.g. vendor CMDQV-based veventq allocation).
No functional change.
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-6-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add a backend helper to mmap hardware MMIO regions exposed via iommufd for
a vIOMMU instance. This allows user space to access HW-accelerated MMIO
pages provided by the vIOMMU.
The caller is responsible for unmapping the returned region.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-5-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nicolin Chen [Tue, 9 Jun 2026 11:25:23 +0000 (12:25 +0100)]
backends/iommufd: Update iommufd_backend_alloc_viommu to allow user ptr
The updated IOMMUFD VIOMMU_ALLOC uAPI allows userspace to provide a data
buffer when creating a vIOMMU (e.g. for Tegra241 CMDQV). Extend
iommufd_backend_alloc_viommu() to pass a user pointer and size to the
kernel.
Update the caller accordingly.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-3-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The updated IOMMUFD uAPI introduces the ability for userspace to request
a specific hardware info data type via IOMMU_GET_HW_INFO. Update
iommufd_backend_get_device_info() to set IOMMU_HW_INFO_FLAG_INPUT_TYPE
when a non-zero type is supplied, and adjust all callers to pass a type
value explicitly initialised to zero (IOMMU_HW_INFO_TYPE_DEFAULT) when
no specific type is requested.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260609112552.378999-2-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This sifive_u only helper shares DT code with other boards. The idea is
to reduce code repetition while keeping sifive_u characteristics in
place.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-14-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The sifive_u board does not share the same CPU socket FDT bits from the
other boards. In particular the riscv,isa creation is done using either
CPU0 from soc.e_cpus.harts, and for all other CPUs soc.u_cups.harts is
used.
It would be too cumbersome to add all these details in the common code
so we're going to add a special sifive_u only helper that shares the
common bits with the common helper used by the other boards.
create_fdt_socket_cpu_internal() contains the common bits shared between
the sifive_u board and the rest.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-13-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Use the new FDT helper to create FDTs for the CPU sockets.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-12-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Consolidate the creation of CPUs socket FDT in a helper that can be
shared across all boards.
The code was basically moved from the function with the same name from
'virt.c', with additional bits to create the cluster subnode beforehand.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-11-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Consolidate the '/cpus' FDT root node creation into a single place.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-10-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
hw/riscv/sifive_u.c: add cpu-map, cluster and core DTs
We want to consolidate the CPU socket FDT creation into a single helper.
'virt' and spike has the same code but sifive_u does not have cpu-map,
cluster and core subnodes.
These subnodes are present in other boards even in single socket configs
without NUMA. This is a strong indicator that their presence doesn't
hurt a NUMA-less board like sifive_u.
Add these DTs to make the FDT standardization straightforward.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-9-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Move all clint FDT generation to fdt-common.c reducing code repetition.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-8-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The clint FDT generation uses a cells array (clint_cells) that are
populated in the middle of the loop that creates the CPU socket FDT.
This is completely fine but it differs from the other boards that
creates the clint cells array right before creating the clint FDT.
'virt' and 'sifive_u' store the intc phandles in a intc_phandles array
during FDT CPU socket creation, and this array is used to create the
clint FDT cells.
Standardize the clint FDT creation for spike doing the same here,
allowing us to move everything to a common helper later.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-7-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Store the intc phandles in an 'intc_phandles' array, like the 'virt'
board does, instead of re-creating the interrupt-controller FDT string
and using qemu_fdt_get_phandle() to fetch it.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-6-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This helper encapsulates the creation of /memory@addr FDT subnodes.
Boards are responsible for calculating the adequate addr, size and
inform if we have numa enabled.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-5-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
There's FDT logic gated around 'numa_enabled()' in virt.c and spike.c.
We want to move the FDT code to a common helper without having to call
hw/riscv/numa.c functions from it, but at the same time being aware of
the FDT changes if numa is enabled.
To do that the boards will inform the FDT helpers if we have
numa_enabled in the env or not. And for the boards to be able to do
that we need the static 'numa_enabled' function to be public.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Message-ID: <20260615203734.954428-4-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
There's too much duplication between RISC-V boards and one of the most
common culprits is the FDT functions.
Add a new file for board FDT helpers. Start by creating a helper that
initializes the FDT and init it with the common board boilerplate.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-3-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
hw/riscv/sifive_u.c: add a FDT phandle to cpu-intc
We're assigning a 'cpu_phandle' phandle to the cpu-intc phandle field.
Make it more in line with the other boards by assigning both a
cpu_phandle and a intc phandle.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260615203734.954428-2-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Chao Liu [Fri, 12 Jun 2026 07:04:08 +0000 (15:04 +0800)]
docs/system/riscv: add documentation for k230 machine
Signed-off-by: Chao Liu <chao.liu.zevorn@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <81d2e2fa42ecabf638f841321cf36cee8f10af01.1781246408.git.chao.liu@processmission.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Chao Liu [Fri, 12 Jun 2026 07:04:06 +0000 (15:04 +0800)]
hw/watchdog: add k230 watchdog initial support
Add programmable Watchdog Timer (WDT) peripheral for K230 machine.
Signed-off-by: Mig Yang <temashking@foxmail.com> Signed-off-by: Chao Liu <chao.liu.zevorn@gmail.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <805a04d9467556ee6a5f4742c9eb4bbb6fc7898c.1781246408.git.chao.liu@processmission.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Chao Liu [Fri, 12 Jun 2026 07:04:05 +0000 (15:04 +0800)]
hw/riscv: add k230 board initial support
K230 Board compatible with Kendryte K230 SDK.
Preliminarily supports the C908 small core, which can run U-Boot and
Linux kernels compiled by the K230 SDK.
The K230 boot flow provides its device tree from firmware or software.
QEMU does not generate a K230 DTB; users can pass one with -dtb for
direct Linux boot, or rely on firmware/kernel built-in DTB for other
payloads.
Signed-off-by: Chao Liu <chao.liu.zevorn@gmail.com> Tested-by: Peng Jiang <3160104094@zju.edu.cn> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <a161697a249b896e44e2748435f6c0caec12c9f4.1781246408.git.chao.liu@processmission.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Chao Liu [Fri, 12 Jun 2026 07:04:04 +0000 (15:04 +0800)]
target/riscv: add thead-c908 cpu support
The C908 processor is based on the RV64GCB[V] instruction
set, compatible to RVA22 Profile and implements the XIE
(XuanTie Instruction Extension) technology.
Signed-off-by: Chao Liu <chao.liu.zevorn@gmail.com> Suggested-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Peng Jiang <3160104094@zju.edu.cn> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <a3e232ace12afd93adb60aed198cac3284daa56c.1781246408.git.chao.liu@processmission.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
imaginos [Sun, 14 Jun 2026 14:12:24 +0000 (16:12 +0200)]
disas/riscv: enable `mnret` disassembly
The translator has supported mnret since commit 3157a553ec6b9a
("target/riscv: Add Smrnmi mnret instruction"), but the
disassembler still renders it as illegal. Add it unguarded,
since the encoding does not overlap any other extension.
Signed-off-by: imaginos <imaginos32@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260614141315.17320-1-imaginos32@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Eric Auger [Wed, 3 Jun 2026 12:44:13 +0000 (14:44 +0200)]
hw/pci/pci: Enforce pci_setup_iommu_per_bus() is called only once per bus
Currently it is possible to attach several arm-smmuv3 devices to the
same bus although it is a wrong setup.
Change the prototype of pci_setup_iommu_per_bus to pass an error
handle. This latter is set when iommu_per_bus is already set and
used by the single caller (smmu_base_realize) to report a useful
error to the end-user.
While at it document pci_setup_iommu_per_bus callback in the header.
Fixes: 66d2f665e163 ("hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation") Signed-off-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@mailo.com>
Message-id: 20260603124415.1120808-1-eric.auger@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:59 +0000 (10:48 -0700)]
hw/arm/smmuv3: Set default ats, ril, ssidsize, oas to auto
Set the default value of ATS, RIL, SSIDSIZE, and OAS to auto, in order
to match the host IOMMU properties when accel=on.
If accel=off and these property values are set to auto, the default
property values defined in smmuv3_init_id_regs() for OAS and RIL will
remain unchanged, while SSIDSIZE and ATS values will remain initialized
at 0.
Introduce a new compat for the changed defaults.
Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-9-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:58 +0000 (10:48 -0700)]
hw/arm/smmuv3-accel: Implement "auto" value for "oas"
Allow accelerated SMMUv3 OAS property to be derived from host IOMMU
capabilities. Derive host values using IOMMU_GET_HW_INFO, retrieving
OAS from IDR5.
This keeps the OAS value advertised by the virtual SMMU compatible with
the capabilities of the host SMMUv3, so that the intermediate physical
addresses (IPA) consumed by host SMMU for stage-2 translation do not
exceed the host's max supported IPA size.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-8-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:57 +0000 (10:48 -0700)]
hw/arm/smmuv3-accel: Implement "auto" value for "ssidsize"
Allow accelerated SMMUv3 SSID size property to be derived from host
IOMMU capabilities. Derive host values using IOMMU_GET_HW_INFO,
retrieving SSID size from IDR1. When the auto SSID size is resolved
to a non-zero value, PASID capability is advertised to the vIOMMU
and accelerated use cases such as Shared Virtual Addressing (SVA)
are supported.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-7-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:56 +0000 (10:48 -0700)]
hw/arm/smmuv3-accel: Implement "auto" value for "ril"
Allow accelerated SMMUv3 Range Invalidation support property to be
derived from host IOMMU capabilities. Derive host values using
IOMMU_GET_HW_INFO, retrieving RIL capability from IDR3.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-6-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:55 +0000 (10:48 -0700)]
hw/arm/smmuv3-accel: Implement "auto" value for "ats"
Allow accelerated SMMUv3 Address Translation Services support property
to be derived from host IOMMU capabilities. Derive host values using
IOMMU_GET_HW_INFO, retrieving ATS capability from IDR0.
Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-5-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:54 +0000 (10:48 -0700)]
hw/arm/smmuv3-accel: Add helper for resolving auto parameters
Introduce smmuv3_accel_auto_finalise() to resolve properties that are
set to 'auto' for accelerated SMMUv3. This helper function allows
properties such as ats, ril, ssidsize, and oas support to be resolved
from host IOMMU capabilities via IOMMU_GET_HW_INFO.
The later commits in this series set the auto_mode flag to true when
an accel SMMUv3 property value is explicitly set to 'auto', or if the
property value is not set and defaults to auto mode.
Setting these property values to 'auto' requires at least one
cold-plugged device to retrieve and finalise these properties. If the
auto_mode flag is true, register a machine_init_done notifier to
verify this requirement and fail boot if it is not met.
Hot-plugged devices into an accel SMMUv3-associated bus will re-use
the resolved host values from the initial cold-plug.
Subsequent patches will make use of this helper to resolve 'auto' to
what is reported by host IOMMU capabilities.
Suggested-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-4-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nathan Chen [Mon, 8 Jun 2026 17:48:52 +0000 (10:48 -0700)]
hw/arm/smmuv3: Update ATC invalidation check
Use smmuv3_ats_enabled() to determine whether ATS is enabled for the
guest when handling an ATC invalidation command, as setting the ATS
property value to 'auto' will resolve to ATS being detected as
enabled in the ATC invalidation check otherwise.
Fixes: f7f5013a55a3 ("hw/arm/smmuv3-accel: Add support for ATS") Reported-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Nathan Chen <nathanc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260608174900.2227340-2-nathanc@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Max Chou [Thu, 11 Jun 2026 10:50:37 +0000 (18:50 +0800)]
target/riscv: rvv: Set mstatus.FS dirty when vector FP raises exceptions
According to the RISC-V privileged spec 3.1.6, any instruction that
modifies FP extension state (FP CSRs including fflags, or f registers)
must set mstatus.FS to Dirty. Raising fflags bits is modifying fcsr
(an FP CSR).
When a vector FP instruction raises a floating-point exception, it
modifies fflags (an FP CSR), but current implementation was not marking
mstatus.FS dirty in this case.
Fix the issue by snapshot fflags before the element loop and OR
MSTATUS_FS into env->mstatus if any new exception bits are set
afterwards.
Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260611105037.157773-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Max Chou [Thu, 11 Jun 2026 10:50:36 +0000 (18:50 +0800)]
target/riscv: Set mstatus.FS dirty when scalar FP raises exceptions
According to the RISC-V privileged spec 3.1.6, any instruction that
modifies FP extension state (FP CSRs including fflags, or f registers)
must set mstatus.FS to Dirty. Raising fflags bits is modifying fcsr
(an FP CSR).
Scalar FP instructions that write integer registers (FP comparisons and
FP-to-integer conversions) never call mark_fs_dirty at translation time
to set mstatus.FS to dirty. However, they can raise FP exception flags
via softfloat functions, which modifies fflags without any mechanism to
dirty mstatus.FS.
The affected helpers:
- Comparisons: fle/fleq/flt/fltq/feq
— raise NV on NaN operands
- FP-to-integer: fcvt.[w|wu|l|lu]/fcvtmod.w.d
— raise NX on inexact or NV on out-of-range
Fix this issue by
1. Save float_exception_flags before the softfloat operation
2. Perform the operation
3. If any new exception bits are set, set fs to dirty
Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260611105037.157773-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The tuple (0 0 0x8000 0) does nothing since it has length = 0. The
information we want to advertise is in the second tuple only. Thus
remove the empty tuple.
While we're at it, seems like we've mistaken the API and we're using
0xffff as 'last address', but in fact it is length. This means that
we're telling the DT we're mapping 0x0 -> 0xfffe, which wasn't our
intention. Therefore change size to '0x10000' to reflect the address
mapping we want (0x0 -> 0xffff).
Found while reviewing the RISC-V Server Platform DT generation, which
happens to copy a lot of code from the 'virt' board, and this nit is
also present there.
Fixes: 2c12de1460 ("hw/riscv/virt: Add IOMMU as platform device if the option is set") Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260608210642.464131-1-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jay Chang [Mon, 18 May 2026 07:22:39 +0000 (15:22 +0800)]
hw/riscv: Refactor riscv_iommu_ctx_put() for Bare mode handling
Align SPEC: Bare mode contexts are not cached, so they require
direct memory deallocation via g_free instead of hash table cleanup.
Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <20260518072239.16293-3-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jay Chang [Mon, 18 May 2026 07:22:38 +0000 (15:22 +0800)]
hw/riscv: Don't insert DDT cache in Bare mode
In Bare mode the IOMMU does not perform DDT look-ups, therefore
caching DDT entries is unnecessary.
Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <20260518072239.16293-2-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Xuemei Liu [Fri, 29 May 2026 10:18:48 +0000 (18:18 +0800)]
hw/riscv/numa.c: Supplement cpu topology arguments
Supplement RISC-V cpu topology arguments, including support socket
cluster and threads per core.
Signed-off-by: Xuemei Liu <liu.xuemei1@zte.com.cn> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260529181848378wiq8pXCmbwAZR5_-wZFJd@zte.com.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Abhigyan Kumar [Sat, 30 May 2026 10:21:00 +0000 (15:51 +0530)]
target/riscv: mask vxrm csrw write to the low 2 bits
Citing the RISC-V specification:
"The vector fixed-point rounding-mode register holds a two-bit
read-write rounding-mode field in the least-significant bits
(vxrm[1:0]). The upper bits, vxrm[XLEN-1:2], should be written as
zeros."
QEMU wrote full value into env->vxrm causing read of upper bits too.
Used existing macros for bit-masking. Previous had a hard-coded value.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3470 Signed-off-by: Abhigyan Kumar <314abh@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260530102100.78150-1-314abh@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Blanchard [Fri, 29 May 2026 05:35:19 +0000 (05:35 +0000)]
target/riscv: Improve alignment in riscv_cpu_dump_state
Align all the CSR values. mcountinhibit is the longest CSR name at
13 characters, so use that width for PC, implicit state, and CSR names.
Also remove the redundant '=' from the implicit state lines.t
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260529053519.1224019-2-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Blanchard [Fri, 29 May 2026 05:35:18 +0000 (05:35 +0000)]
target/riscv: Print privilege level and ELP in riscv_cpu_dump_state
The privilege level and ELP are implicit state (like virt), so print them
out.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260529053519.1224019-1-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Frank Chang [Thu, 28 May 2026 05:42:13 +0000 (13:42 +0800)]
target/riscv: Add standard B extension implied rule
Add the missing implied rule for standard B extension.
Standard B extension implies Zba, Zbb, Zbs extensions.
We can also remove the auto-enables in riscv_cpu_validate_b()
as Zba, Zbb, Zbs extensions can be enabled by the implied rule.
RISC-V B spec: https://github.com/riscv/riscv-b
Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Frank Chang <frank.chang@sifive.com> Signed-off-by: Frank Chang <frank.chang@sifive.com>
Message-ID: <20260528054213.678458-3-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jim Shu [Thu, 28 May 2026 05:42:12 +0000 (13:42 +0800)]
target/riscv: Add the implied rule for G extension
Add the missing implied rule from G to imafd_zicsr_zifencei.
We can also remove the auto-enables in riscv_cpu_validate_g() as
IMAFD, Zicsr, Zifencei extensions can be enabled by the implied rule.
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260528054213.678458-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: Expose and document the CPU 'big-endian' property
Now that the full big-endian data path is in place (runtime MSTATUS
bits, boot code, and page-table walks), expose the "big-endian"
property to users via DEFINE_PROP_BOOL and document it in
docs/system/target-riscv.rst.
Document that the property models fixed-endian hardware: it selects
harts whose MBE/SBE/UBE fields are fixed to 1, and it does not model
a mixed-endian implementation where software can toggle those bits at
runtime.
The property can be enabled from the command line, e.g.:
-cpu <cpu>,big-endian=on
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-12-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Check the hart endianness property and use it throughout the boot code:
- ELF loading: pass ELFDATA2MSB or ELFDATA2LSB based on endianness
- Firmware dynamic info
- Reset vector: instructions (entries 0-5) remain always little-endian,
data words (entries 6-9) use target data endianness.
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Co-developed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-11-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: Add big-endian CPU configuration field and reset logic
Add a big_endian field to RISCVCPUConfig and wire it into the CPU
reset path. When cfg.big_endian is set, riscv_cpu_reset_hold()
writes 1 into the MSTATUS MBE/SBE/UBE fields using set_field();
otherwise it writes 0. This makes the reset value deterministic on
both cold and warm reset.
This models fixed-endian harts, not mixed-endian implementations where
the guest can toggle MBE/SBE/UBE at runtime. The MBE/SBE/UBE bits are
not included in the writable mask of any mstatus/mstatush/sstatus CSR
write path (unchanged by this series), so the value chosen at reset is
effectively hardwired per section 3.1.6.5 of the RISC-V Privileged
Specification.
The user-facing property and documentation are added in a later patch,
once the full endianness support is in place.
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-10-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
hw/riscv/boot: Rewrite setup_rom_reset_vec() using load/store API
In order to make the following commits easier to review, do
not pre-initialize the reset_vec[] array, fill each word one
by one. Set the start and FDT load addresses using the load/
store APIs.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-8-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: Fix page table walk endianness for big-endian harts
The page table walker reads PTEs using address_space_ldl/ldq which use
compile-time native endianness (always LE for RISC-V). However, when a
big-endian kernel writes PTEs via normal store instructions, they are
stored in big-endian byte order. The walker then misinterprets the PTE
values, causing page faults and a hang when the kernel enables the MMU.
The RISC-V privileged specification states that implicit data memory
accesses to supervisor-level memory management data structures follow
the hart's endianness setting (MSTATUS SBE/MBE bits).
Fix both PTE reads and atomic A/D bit updates to use the explicit _le
or _be memory access variants based on the hart's runtime endianness.
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-7-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: De-indent some code in get_physical_address()
get_physical_address() is quite complex already. In order
to make the two next commits simplers, de-indent one if()
ladder. No logical change intended.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-5-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: Implement runtime data endianness via MSTATUS bits
Make data accesses honour the MSTATUS MBE/SBE/UBE endianness bits
instead of being hardcoded to little-endian. Update mo_endian_env()
to pick the bit corresponding to the current privilege level (MBE
for M, SBE for S, UBE for U). Remove the now unused mo_endian()
helper.
Note, TB_FLAGS has no free bits, so the data endianness is carried
in the extended RISC-V TB flags stored in cs_base. It uses
EXT_TB_FLAGS.BIG_ENDIAN at bit 33, leaving bit 32 for
EXT_TB_FLAGS.ALTFMT. This keys TBs correctly on the current data
endianness.
Instruction fetches remain MO_LE unconditionally; RISC-V instructions
are always little-endian per the ISA specification. Update the
disassembler comment to clarify that BFD_ENDIAN_LITTLE is correct.
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Co-developed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-3-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: Initialize DisasContext::mo_endian once
The data access endianness is constant during a translation
block; rather than calling the mo_endian() method each time,
initialize the DisasContext::mo_endianness field once in
TranslatorOps::init_disas_context().
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260527201348.29511-2-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
inst_length() can return 0 if 'inst' happens to not match any known
encoding (like [1]). Returning 0 is not desirable, even for unknown
encodings, given that it will cause a loop in target_disas() later on.
The most recent version of the RISC-V unpriv spec ditched the
sophisticated instruction-length encoding. We're now supporting only
16-bit and 32-bit length instructions, where:
"All the 32-bit instructions in the base ISA have their lowest two bits
set to 11. The optional compressed 16-bit instruction-set extensions
have their lowest two bits equal to 00, 01, or 10."
So the code is now simpler, never returning 0, and in fact it's the same
thing we're already doing in insn_len() from target/riscv/internals.h.
Due to include shenarigans we can't use that function in disas/riscv.c,
but I believe we can cut ourselves some slack this time and not lose
sleep over a 1 line of duplicated logic. We're documenting it though!
Stefan Hajnoczi [Mon, 15 Jun 2026 20:48:38 +0000 (16:48 -0400)]
Merge tag 'pbouvier/pr/tests-20260615' of https://gitlab.com/p-b-o/qemu into staging
Changes:
- [PATCH v2 0/5] tests: update ubuntu2204 to ubuntu2404 (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>) Link: https://lore.kernel.org/qemu-devel/20260610192222.2709135-1-pierrick.bouvier@oss.qualcomm.com
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEN8FWlNi6l2Sxlz/btEQ30ZwoYt8FAmowO3QACgkQtEQ30Zwo
# Yt/5igv/Tq5Gz4eSwPaGRJqx7bocO61oplBINkT7h+2x6G310rnqPCQGcrGFkQx0
# hkBNq/ZsHDX0eYuc+65qTwlZg77jG6YBpXsMefcY2zpKpxapM6J+Ev1+CrvZeHu2
# ad18fJiRlPYS6i82bG+iBU992q+Tlu4OxrCaxxqcudIr6ZI0JBb/0wqxRjzuuHqY
# xtD5K19Ma5cXJa6CbepT5AMOIc9zlyWP0LNPbY8XdJvg8FTq52nndRuvatuzDNGN
# 5Qj+rMPGodQh3FrcPbZbreWBkq3W3ZSmoYB/7pB8HFwTwvb2Z830hP47C8s0os6E
# nLHOy2PUohfL/F3fnKzHGTdnL3dFuc1c3KATwSj1E6O8VhRGv/j2SLQnUVS7mn3v
# bDUqt02NhjIvcXyUFyPzQ58d65++XIKIWq4ZXrLHXqEGYCkgZLwGaQHvfhH5NVGi
# Z2mb0FdZOb7RgOljzN7qkkBUQbyANHWZJzJmXSjyXDsuRti3T85JXhtJXBQ9RVlc
# 9U5VOmlU
# =QDsb
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 15 Jun 2026 13:50:44 EDT
# gpg: using RSA key 37C15694D8BA9764B1973FDBB44437D19C2862DF
# gpg: Good signature from "Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 37C1 5694 D8BA 9764 B197 3FDB B444 37D1 9C28 62DF
* tag 'pbouvier/pr/tests-20260615' of https://gitlab.com/p-b-o/qemu:
tests: remove ubuntu2204 container
ci: update to ubuntu2404
docs: update mention to ubuntu2204
tests: add ubuntu 2404
net/af-xdp.c: maybe-uninitialized warning with gcov build on ubuntu2404
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
intel_iommu:
PASID support for passthrough
some properties renamed
virtio-rtc:
new device
acpi:
watchdog (x86 q35)
COM irqs are now shared
vhost-user:
vhost-user passes GPA not HVA now
vhost SHMEM_MAP/UNMAP support
vhost-vdpa:
svq IN_ORDER support
amd_iommu:
IOMMU XT interrupt support
command buffer fixes
cxl:
PPR support
performant path for non-interleaved cases
vhost-scsi:
build fix for older kernel headers
fixes, cleanups all over the place
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (106 commits)
hw/scsi/vhost-scsi: fix build with older kernel headers
tests/qtest: add 8-byte MMIO access sweep for intel-iommu
intel_iommu: fix guest-triggerable abort on oversized MMIO access
hw/cxl: Add a performant (and correct) path for the non interleaved cases
hw/cxl: Allow cxl_cfmws_find_device() to filter on whether interleaved paths are accepted
hw/cxl/events: Fix handling of component ID in event records generation to not assume it is a string
hw/cxl: Add fixes in Post Package Repair (PPR)
hw/cxl: Fix handling of component ID to not assume it is a string
vhost-user.rst: fix typo
vhost-user-device: Add shared memory BAR
qmp: add shmem feature map
vhost_user.rst: Add GET_SHMEM_CONFIG message
vhost_user: Add frontend get_shmem_config command
vhost_user.rst: Add SHMEM_MAP/_UNMAP to spec
vhost_user.rst: Align VhostUserMsg excerpt members
vhost-user: Add VirtIO Shared Memory map request
tests: acpi: x86/q35: update expected WDAT blob
tests: acpi: x86/q35: add WDAT table test case
tests: acpi: x86/q35: whitelist new WDAT table
x86: q35: generate WDAT ACPI table
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Quan Sun [Mon, 25 May 2026 18:27:30 +0000 (11:27 -0700)]
hw/scsi/vhost-scsi: fix build with older kernel headers
On build hosts with kernel headers older than 6.0, the system's
<linux/vhost_types.h> does not define struct vhost_vring_worker or
struct vhost_worker_state, causing compilation of vhost-scsi.c to
fail:
error: storage size of 'vq_worker' isn't known
Fix by including standard-headers/linux/vhost_types.h before the
system's <linux/vhost.h>, matching the existing pattern used in
hw/virtio/vhost-backend.c. QEMU's bundled header provides the
struct definitions, and its include guard prevents redefinition
when the system header pulls in its own vhost_types.h.
Signed-off-by: Quan Sun <Quan.Sun@windriver.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260525182730.4098543-1-Quan.Sun@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Junjie Cao [Thu, 14 May 2026 18:07:03 +0000 (02:07 +0800)]
tests/qtest: add 8-byte MMIO access sweep for intel-iommu
Sweep every 4-byte-aligned offset in the VT-d MMIO register space
with 8-byte reads and writes to verify that no register handler
aborts on an oversized access.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260514180703.85686-3-junjie.cao@intel.com>
Junjie Cao [Thu, 14 May 2026 18:07:02 +0000 (02:07 +0800)]
intel_iommu: fix guest-triggerable abort on oversized MMIO access
An 8-byte guest access to a 32-bit-only VT-d register hit
assert(size == 4) and aborted QEMU. Remove all 25 asserts.
All 3 read-side and 18 of 22 write-side asserts are at
non-8-aligned offsets (unreachable, rejected by
memory_region_access_valid()) -- simply deleted.
The remaining 4, all writes at 8-aligned offsets, are
reachable: FECTL 0x38, IECTL 0xa0, IEADDR 0xa8, PECTL 0xe0.
Truncating the high half via vtd_set_long() matches prior
behavior; log under -d guest_errors since the VT-d spec is
silent on oversized accesses to 32-bit registers, and add a
comment so future maintainers don't delete the check as
"harmless". min_access_size stays 4, so all size-based
branches on 64-bit register pairs are preserved.
Found by generic-fuzz (24 distinct crash seeds, all fixed).
Suggested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260514180703.85686-2-junjie.cao@intel.com>
Alireza Sanaee [Wed, 18 Mar 2026 17:19:17 +0000 (17:19 +0000)]
hw/cxl: Add a performant (and correct) path for the non interleaved cases
The CXL address to device decoding logic is complex because of the need to
correctly decode fine grained interleave. The current implementation
prevents use with KVM where executed instructions may reside in that memory
and gives very slow performance even in TCG.
In many real cases non interleaved memory configurations are useful and for
those we can use a more conventional memory region alias allowing similar
performance to other memory in the system.
Whether this fast path is applicable can be established once the full set
of HDM decoders has been committed (in whatever order the guest decides to
commit them). As such a check is performed on each commit/uncommit of HDM
decoder to establish if the alias should be added or removed.
Reviewed-by: Li Zhijian <lizhijian@fujitsu.com> Co-developed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gregory Price <gourry@gourry.net> Tested-by: Gregory Price <gourry@gourry.net> Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260318171918.146-4-alireza.sanaee@huawei.com>
Alireza Sanaee [Wed, 18 Mar 2026 17:19:16 +0000 (17:19 +0000)]
hw/cxl: Allow cxl_cfmws_find_device() to filter on whether interleaved paths are accepted
Extend cxl_cfmws_find_device() with a parameter that filters on whether the
address lies in an interleaved range. For now all callers accept
interleave configurations so no functional changes.
Reviewed-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gregory Price <gourry@gourry.net> Tested-by: Gregory Price <gourry@gourry.net> Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20260318171918.146-3-alireza.sanaee@huawei.com>
Pierrick Bouvier [Wed, 10 Jun 2026 19:22:18 +0000 (12:22 -0700)]
net/af-xdp.c: maybe-uninitialized warning with gcov build on ubuntu2404
This is a false positive, fixed by explicitly initializing
variable to NULL. Variable is always initialized during the for loop
above, which is guaranteed to run since queues >= 1.
This is correctly detected for normal builds, but not for gcov builds.
In function ‘af_xdp_read_poll’,
inlined from ‘net_init_af_xdp’ at ../net/af-xdp.c:546:5:
../net/af-xdp.c:78:10: error: ‘s’ may be used uninitialized [-Werror=maybe-uninitialized]
78 | if (s->read_poll != enable) {
| ~^~~~~~~~~~~
../net/af-xdp.c: In function ‘net_init_af_xdp’:
../net/af-xdp.c:461:17: note: ‘s’ was declared here
461 | AFXDPState *s;
|
John Snow [Thu, 11 Jun 2026 04:23:21 +0000 (00:23 -0400)]
tests/qapi: generate output in source order
Rewrite the test doc generator to produce output in source order instead
of arbitrarily by section name.
This patch removes our last use of the "body" field, which has an
effect on how the sections of each test documention block are
printed. We now print the name of the section followed by the section
text for all sections except Members and Features, which are printed
as "Member=%s" or "Feature=%s" followed by the section text,
respectively.
This patch is motivated by a desire to move the QAPIDoc API away from
named fields for specific sections in a bid to force all users to simply
iterate through all_sections in order, instead - and to remove the named
subsections.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20260611042332.482979-3-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
John Snow [Thu, 11 Jun 2026 04:23:20 +0000 (00:23 -0400)]
python: temporarily restrict max mypy version
The newest versions of mypy do not support targeting Python 3.9, which
we still support. I want to address that soon, but in the meantime
it's nice if the tests pass.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20260611042332.482979-2-jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Filip Hejsek [Tue, 9 Jun 2026 12:01:27 +0000 (14:01 +0200)]
qapi: drop "must exist" from ID descriptions for consistency
Make chardev ID param descriptions more consistent with ID descriptions
elsewhere.
Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com>
Message-ID: <20260609120221.461303-1-filip.hejsek@gmail.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
target/riscv/tcg: disable svnapot if satp_mode < sv39
We did a recent change to disable svpbmt if satp_mode < sv39 that was
discovered via a gitlab report.
This time we don't have an opened bug but the problem is similar: RISC-V
privileged ISA, chapter '"Svnapot" Extension for NAPOT Translation
Contiguity, Version 1.0' states:
"The Svnapot extension depends on the Sv39 extension."
Do the same thing with svnapot, including the user warning in case we
try to enable it without the required satp_mode:
$ ./build/qemu-system-riscv64 -M virt,dumpdtb=fdt.dtb \
-cpu max,sv39=off,sv48=off,sv57=off,sv64=off,svnapot=on
qemu-system-riscv64: warning: svnapot requires at least satp sv39, current satp mode: none
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260527213034.2094103-1-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
We're not doing anything special w.r.t PMA (Physical Memory Access)
related faults, handling them like regular faults that will eventually
turn to be regular page faults.
Turns out we can't do that. Priv spec section "Virtual Address
Translation Process" mentions:
"If a store to the PTE at address a+va.vpn[i]×PTESIZE would violate a
PMA or PMP check, raise an access-fault exception corresponding to the
original access type."
This means that we should handle PMA violations with access faults, like
we're already doing with PMP. One clear code path where we should throw
a PMA failure, exposed by [1], is the error return from
address_space_ld* call.
There's a separated issue with the error code being returned by them (it
always return DECODE_ERROR even with 'rejected' reads) that we're going
to work around it by assuming that we did a good job with the PTE
address sanitization beforehand, and interpret that the error here is
related to PMA. This is of course not ideal but fixing this QEMU API is
out of scope for this work.
All this said, we'll set the new pmp_pma_violation flag when we have
either a PMP or a PMA fault, and everything else shall fall into place.
Anton Johansson [Wed, 20 May 2026 12:54:05 +0000 (14:54 +0200)]
target/riscv: Fix pmp.h/cpu.h circular inclusion
pmp.h is only needed and included for system mode, however relevant
macros (MAX_RISCV_PMPS, OLD_MAX_RISCV_PMPS, MIN_RISCV_PMP_GRANULARITY)
are required unconditionally by cpu.c, and so are defined in cpu.h.
pmp.h then defines pmp_table_t depending on these macros and so requires
cpu.h, and cpu.h in turn uses pmp_table_t resulting in circular
inclusion.
Move PMP macros to pmp.h and only expose PMP properties in system mode.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-28-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:54:04 +0000 (14:54 +0200)]
target/riscv: Pass address as uint64_t in cpu_set_exception_base()
The corresponding field CPUArchState::resetvec is uint64_t anyway, no
need to use target_ulong.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-27-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:54:03 +0000 (14:54 +0200)]
target/riscv: Make pmp.h target_ulong agnostic
The pmp.h header is exposed through cpu.h. pmp_table_t is also used in
CPUArchState. CSR declarations are only used in target/ and are moved to
csr.h. In pmp.h, addr_reg is widened to 64 bits and the privilege mode
parameter is fixed to 8 bits, similar to previous commits.
Note, the cpu/pmp/entry and cpu/pmp VMSTATE versions are bumped, breaking
migration from older versions.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-26-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Convert riscv_csr_[read|write]() into target_ulong angnostic CSR access
functions that can be safely used from outside of target/ without
knowledge of the target register size. Replace the 4 existing CSR
accesses in hw/ and linux-user/.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-25-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:54:01 +0000 (14:54 +0200)]
target/riscv: Move CSR declarations to separate csr.h header
Most of these definitions save riscv_csrr, riscv_csrrw, riscv_csr_read,
riscv_csr_write are only used in target/. Move declarations to a
separate headers which will soon be made internal to target/.
csr.h is temporarily included from cpu.h to not break includes from
outside target/, this include will be removed in the following commit.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-24-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:54:00 +0000 (14:54 +0200)]
target/riscv: Move debug.h include away from cpu.h
All debug.h definitions except for RV_MAX_TRIGGERS are internal to
target/riscv. Move RV_MAX_TRIGGERS to cpu.h and include debug.h from
all translation units which relied on the cpu.h include.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260520125406.28693-23-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:53:59 +0000 (14:53 +0200)]
target/riscv: Fix size of mseccfg
mseccfg is defined in version 20250508 of the privileged specification
to be 64 bits in size. Update relevant function arguments.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-22-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:53:58 +0000 (14:53 +0200)]
target/riscv: Fix size of trigger data
mcontext is at most 14 bits in size with the H extension, fix to 16
bits. trigger_cur indexes into tdata*[RV_MAX_TRIGGERS] which holds 2
elements, fix to 8 bits.
This patch also adds a migration entry for mcontext which is used in
tandem with other debug data that is already migrated.
Note, the cpu/debug VMSTATE version is bumped, breaking migration from
older versions.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-21-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Johansson [Wed, 20 May 2026 12:53:57 +0000 (14:53 +0200)]
target/riscv: Replace target_ulong in riscv_ctr_add_entry()
Widen to 64 bits in size to hold all relevant values. Note: src and dst
arguments change from signed to unsigned but no functional change is
incurred.
Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260520125406.28693-20-anjo@rev.ng> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
projects / thirdparty / qemu.git / log
