When using a CXL Type 3 device together with a virtio 9p device in QEMU, the
9p device fails to initialize properly. The kernel reports the following:
virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with
> -Original Message-
> From: Nicolin Chen
> Sent: Friday, July 18, 2025 9:12 AM
> To: Shameerali Kolothum Thodi
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
> ddut...@redhat.com; berra...@redhat.com; imamm...@redh
> -Original Message-
> From: Nicolin Chen
> Sent: Friday, July 18, 2025 5:14 AM
> To: Shameerali Kolothum Thodi
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
> ddut...@redhat.com; berra...@redhat.com; imamm...@redh
after launch. For example, when the PSP is launched first
to enable SSP via SCU, the test framework cannot dynamically attach to the SSP
console afterward to verify its behavior.
Due to this limitation, the test case for AST2700FC has been modified to use
vBootROM (`ast27x0_bootrom.bin`) instead of
In the previous design, both the PSP and TSP were started together during
SoC initialization. However, on real hardware, the TSP begins in a powered-off
state. The typical boot sequence involves the PSP powering up first, loading
the TSP firmware binary into shared memory via DRAM remap, and then
The updated boot ROM includes logic to initialize and enable SSP/TSP using SCU
registers, based on reserved-memory regions defined in the device tree.
Its source code is available at:
https://github.com/google/vbootrom/commit/f9eb0bb57decbab860a81712c56132c2102fa98e
Build Information:
Build Date
This patch implements TSP reset and power control logic in the SCU module
for AST2700. It introduces support for the following behavior:
1. TSP Reset Trigger (via SCU 0x224):
- TSP reset is triggered by writing 1 to bit 9 (RW1S) of SYS_RESET_CTRL_2.
2. TSP Reset State and Source Hold (via
This commit adds SCU register support for SSP SDRAM remap control and runtime
activation. It introduces logic for the PSP to dynamically configure the mapping
of its own DRAM windows into SSP-visible SDRAM space, enabling shared memory
communication via memory region aliases.
Two MemoryRegion
mory between the main CPU (PSP) and the
+ * coprocessors. Coprocessors access this shared SRAM region through a
+ * MemoryRegion alias mapped to a different physical address.
+ *
+ * Similarly, the SCU is a single hardware block shared across all
+ * processors. Coprocessors ac
``-device loader``:
+
+In this approach, users manually load firmware and assign entry points via
QEMU loader devices.
+By default, the PSP begins execution at address ``0x43000``, the load
address of the bl31
+firmware. The SSP and TSP start in the powered-off state and must be
explicitly
AST2700 has a 128KB SRAM, physically mapped at 0x1000–0x1001 for the
main CA35 processor. The TSP coprocessor accesses this same memory at a
different memory address: 0x7000–0x7001.
To support this shared memory model, this commit introduces "tsp.sram_mr_alias",
a "MemoryRegion" al
AST2700 has a 128KB SRAM, physically mapped at 0x1000–0x1001 for the
main CA35 processor. The SSP coprocessor accesses this same memory at a
different memory address: 0x7000–0x7001.
To support this shared memory model, this commit introduces "ssp.sram_mr_alias",
a "MemoryRegion" al
This commit adds a MemoryRegion alias to support PSP access to
TSP SDRAM through shared memory remapping, as defined by the default SCU
configuration.
The TSP coprocessor exposes one DRAM alias:
- remap maps PSP DRAM at 0x42e00 (32MB) to TSP SDRAM offset 0x0
This region corresponds to the d
window.
One MemoryRegion alias is attached to the SCU via QOM property link:
- tsp-sdram-remap: maps PSP DRAM at 0x42E00 (size: 32MB) to TSP SDRAM
offset 0x0
The SCU registers AST2700_SCU_TSP_CTRL_1 and
AST2700_SCU_TSP_REMAP_SIZE_2 allow runtime reconfiguration of the DRAM base
(alias
at a specific offset. This alias is
mapped into the coprocessor's SDRAM address space, allowing both PSP and the
coprocessor (SSP/TSP) to access the same physical memory through their
respective
views — PSP via its DRAM, and the coprocessor via its SDRAM.
The remapping is configured throug
U register defaults.
+ * Therefore, DRAM must be fully initialized before coprocessors can
+ * attach aliases to it.
*
- * Similarly, the SCU is a single hardware block shared across all
- * processors. Coprocessors access it via a MemoryRegion alias that maps
- * t
AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA35 processor (PSP). The TSP coprocessor
accesses
this same SCU block at a different address: 0x72C02000–0x72C03FFF.
To support this shared SCU model, this commit introduces "tsp.scu_
In the previous design, both the PSP and SSP were started together during
SoC initialization. However, on real hardware, the SSP begins in a powered-off
state. The typical boot sequence involves the PSP powering up first, loading
the SSP firmware binary into shared memory via DRAM remap, and then
This patch implements SSP reset and power control logic in the SCU for AST2700.
It introduces support for the following behavior:
1. SSP Reset Trigger (via SCU 0x220):
- SSP reset is triggered by writing 1 to bit 30 (RW1S) of SYS_RESET_CTRL_1.
2. SSP Reset State and Source Hold (via SCU 0x120
According to the AST2700 design, the TSP coprocessor uses its own SDRAM
instead of SRAM. Additionally, all three coprocessors—SSP, TSP, and PSP—share
a common SRAM block. In the previous implementation, the TSP memory region
was labeled and sized as "SRAM", but in practice it was being used as TSP'
Introduces support for loading a vbootrom image into the dedicated vbootrom
memory region in the AST2700 Full Core machine.
Additionally, it implements a mechanism to extract the content of fmc_cs0
flash data(backend file) and copy it into the memory-mapped region
corresponding to ASPEED_DEV_SPI_B
In the previous design, the SSP coprocessor (aspeed27x0ssp-soc) was initialized
and realized at the machine level (e.g., AST2700FC). However, to make sure the
coprocessors can work together properly—such as using the same SRAM, sharing
the SCU, and having consistent memory remapping—we need to chan
According to the AST2700 design, the SSP coprocessor uses its own SDRAM
instead of SRAM. Additionally, all three coprocessors—SSP, TSP, and PSP—share
a common SRAM block. In the previous implementation, the SSP memory region
was labeled and sized as "SRAM", but in practice it was being used as SSP'
In the previous design, the TSP coprocessor (aspeed27x0tsp-soc) was initialized
and realized at the machine level (e.g., AST2700FC). To allow proper
integration between coprocessors—such as shared use of SRAM, SCU, and memory
remap configuration—this commit moves TSP initialization into the AST2700
coprocessor reset via SCU registers.
Jamin Lin (21):
hw/arm/aspeed_ast27x0-fc: Support VBootRom
hw/arm/ast27x0: Move SSP coprocessor initialization from machine to
SoC leve
hw/arm/ast27x0: Move TSP coprocessor initialization from machine to
SoC leve
hw/arm/aspeed_ast27x0-ssp: Switch SSP
On Tue, Jul 15, 2025 at 08:19:04AM +0200, Cédric Le Goater wrote:
> commit ad8e0e8a0088 removed the "==" underlining the file title
> which broke documentation rendering. Add it back.
>
> Fixes: ad8e0e8a0088 ("docs: add support for gb200-bmc")
> Cc: Ed Tanous
> Reported-by: Peter Maydell
> S
> -Original Message-
> From: Nicolin Chen
> Sent: Wednesday, July 16, 2025 3:58 AM
> To: Shameerali Kolothum Thodi
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org;
> eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
> ddut...@redhat.com; berra...@redhat.com; nath...@nvi
On Wed, Jul 16, 2025 at 05:23:57PM +0800, Yi Liu wrote:
> On 2025/7/16 12:05, Konstantin Belousov wrote:
> > On Wed, Jul 16, 2025 at 12:01:44PM +0800, Yi Liu wrote:
> > > On 2025/7/15 20:27, CLEMENT MATHIEU--DRIF wrote:
> > > >
> > > >
> > > > On 15/07/2025 10:27 am, David Woodhouse wrote:
> > >
On Tue, 15 Jul 2025 10:01:21 -0700
Nicolin Chen wrote:
> On Tue, Jul 15, 2025 at 11:29:41AM +0100, Jonathan Cameron wrote:
> > > +if (!iommufd_backend_alloc_viommu(idev->iommufd, idev->devid,
> > > + IOMMU_VIOMMU_TYPE_ARM_SMMUV3,
> > > +
backend is allowed with
> >> >arm-smmuv3,accel=on",
> >> >+ pdev->name);
> >> >+exit(1);
> >>
> >> Seems aggressive for a hotplug, could we fail hotplug instead of kill
> QEMU?
> >
> >Hotpl
> -Original Message-
> From: Duan, Zhenzhong
> Sent: Wednesday, July 16, 2025 4:39 AM
> To: Nicolin Chen
> Cc: Shameerali Kolothum Thodi
> ; qemu-...@nongnu.org;
> qemu-devel@nongnu.org; eric.au...@redhat.com;
> peter.mayd...@linaro.org; j...@nvidia.com; ddut...@redhat.com;
> berra...@
accel) {
> > +return;
> > + }
> > +
> > +g_hash_table_foreach(bs->configs, smmuv3_accel_ste_range, range);
>
> This will not work correctly?
>
> The bs->configs is a cache that gets an entry inserted to when a
> config is fetched via sm
But things like IORT mappings aren't able
> to get refreshed since the OS is likely already booted.
Why do we need IORT mappings to be refreshed during hotplug?
AFAICS, the mappings are created per host bridge Ids. And how is this
different from a host machine doing hotplug?
Even an
>
> -Original Message-
> From: Nicolin Chen
> Sent: Tuesday, July 15, 2025 6:23 PM
> To: Jonathan Cameron
> Cc: Shameerali Kolothum Thodi
> ; Linuxarm
> ; qemu-...@nongnu.org; qemu-
> de...@nongnu.org; eric.au...@redhat.com; peter.mayd...@linaro.org;
> j...@nvidia.com; ddut...@redhat.com
> -Original Message-
> From: Duan, Zhenzhong
> Sent: Tuesday, July 15, 2025 11:46 AM
> To: Shameerali Kolothum Thodi
> ; qemu-...@nongnu.org;
> qemu-devel@nongnu.org
> Cc: eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
> nicol...@nvidia.com; ddut...@redhat.com; berra..
On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Not all fields in the SMMU IDR registers are meaningful for userspace.
> Only the following fields can be used:
>
> - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16, TTF
> - IDR1: SI
On Mon, 14 Jul 2025 16:59:41 +0100
Shameer Kolothum wrote:
> Now user can set "accel=on". Have fun!
>
> Signed-off-by: Shameer Kolothum
Hard to argue with this one ;)
Reviewed-by: Jonathan Cameron
> ---
> hw/arm/smmu-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/arm
On Mon, 14 Jul 2025 16:59:40 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Not all fields in the SMMU IDR registers are meaningful for userspace.
> Only the following fields can be used:
>
> - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16, TTF
> - IDR1: SIDSIZE
On Mon, 14 Jul 2025 16:59:39 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Use the provided smmuv3-accel helper functions to issue the
> invalidation commands to host SMMUv3.
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Shameer Kolothum
> ---
> hw/arm/smmuv3-internal.h | 11 +++
On Mon, 14 Jul 2025 16:59:38 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Helpers will batch the commands and issue at once to host SMMUv3.
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Shameer Kolothum
> ---
> hw/arm/smmuv3-accel.c| 65 +
On Mon, 14 Jul 2025 16:59:34 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Implement a set_iommu_device callback:
> -If found an existing viommu reuse that.
>(Devices behind the same physical SMMU should share an S2 HWPT)
> -Else,
> Allocate a viommu with the nested parent S2
the IOMMU address space
>
> Note: On ARM, MSI doorbell addresses are also translated via SMMUv3.
> Hence, if a vfio-pci device is behind the SMMuv3 with translation enabled,
> it must return the IOMMU address space for MSI. Support for this will be
> added in a follow-up patc
On Mon, 14 Jul 2025 16:59:31 +0100
Shameer Kolothum wrote:
> Also setup specific PCIIOMMUOps for accel SMMUv3 as accel
> SMMUv3 will have different handling for those ops callbacks
> in subsequent patches.
>
> The "accel" property is not yet added, so users cannot set it at this
> point. It will
On Mon, 14 Jul 2025 16:59:30 +0100
Shameer Kolothum wrote:
> Allows to retrieve the PCIIOMMUOps based on the SMMU type. This will be
> useful when we add support for accelerated SMMUV3 in subsequent patches
> as that requires a different set of callbacks for iommu ops.
>
> No special handling is
On Mon, 14 Jul 2025 16:59:29 +0100
Shameer Kolothum wrote:
> Subsequent patches for smmuv3 accel support will make use of this.
>
> Signed-off-by: Nicolin Chen
> Reviewed-by: Eric Auger
> Signed-off-by: Shameer Kolothum
Various trivial things inline. In general looks fine.
J
> ---
> hw/ar
On Mon, 14 Jul 2025 16:59:28 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Add a helper to allocate an iommufd device's virtual device (in the user
> space) per a viommu instance.
Same trivial suggestion as in patch 1. Also feel free to ignore.
On Mon, 14 Jul 2025 16:59:27 +0100
Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Add a helper to allocate a viommu object.
>
> Signed-off-by: Nicolin Chen
> Reviewed-by: Eric Auger
> Signed-off-by: Shameer Kolothum
One trivial comment inline. Feel free to ignore.
> ---
> backends/iomm
On Mon, Jul 14, 2025 at 05:41:22PM +0100, David Woodhouse wrote:
> On 14 July 2025 15:28:09 GMT+01:00, Yi Liu wrote:
> >Hi David,
> >
> >On 2025/7/14 16:00, David Woodhouse wrote:
> >> From: David Woodhouse
> >>
> >> FreeBSD does both, and this appears to be perfectly valid. The VT-d
> >> spec e
On Mon, Jul 14, 2025 at 09:14:17AM -0700, Nicolin Chen wrote:
> Hi Shameer,
>
> Thank you for sending the v3.
>
> On Mon, Jul 14, 2025 at 04:59:26PM +0100, Shameer Kolothum wrote:
> > Branch for testing:
> [...]
> > Tested on a HiSilicon platform with multiple SMMUv3s.
> >
> > ./qemu-system-aarc
On Mon, Jul 14, 2025 at 01:04:02PM -0700, Nicolin Chen wrote:
> On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote:
> > From: Nicolin Chen
> >
> > Not all fields in the SMMU IDR registers are meaningful for userspace.
> > Only the following fields can be used:
> >
> > - IDR0: ST_
On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote:
> From: Nicolin Chen
>
> Not all fields in the SMMU IDR registers are meaningful for userspace.
> Only the following fields can be used:
>
> - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16, TTF
> - IDR1: SI
On Mon, 14 Jul 2025 10:04:44 +0200
Eric Auger wrote:
> This series enables ACPI PCI hotplug/hotunplug on ARM.
> It is not enabled by default and ACPI PCI hotplug can
> be selected by setting:
>
> -global acpi-ged.acpi-pci-hotplug-with-bridge-support=on
>
> Expected benefits should be similar t
On 7/14/25 5:12 PM, Ilya Maximets wrote:
On 7/11/25 11:44 AM, Daniel Borkmann wrote:
Extend 'inhibit=on' setting with the option to specify a pinned XSK map
path along with a starting index (default 0) to push the created XSK
sockets into. Example usage:
# ./build/qemu-system-x86_64 [...] \
From: Anisa Su
Prepatory patch for following FMAPI Add/Release Patches. Refactors part
of qmp_cxl_process_dynamic_capacity_prescriptive() into a helper
function to create DC Event Records and insert in the event log.
Moves definition for CXL_NUM_EXTENTS_SUPPORTED to cxl.h so it can be
accessed b
From: Anisa Su
Add a lock on the bitmap of each CXLDCRegion in preparation for the next
patch which implements FMAPI Set DC Region Configuration. This command
can modify the block size, which means the region's bitmap must be updated
accordingly.
The lock becomes necessary when commands that add
From: Anisa Su
FM DCD Management command 0x5605 implemented per CXL r3.2 Spec Section 7.6.7.6.6
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-mailbox-utils.c | 88 ++
1 file changed, 88 insertions(+)
diff --git
From: Anisa Su
FM DCD Management command 0x5602 implemented per CXL r3.2 Spec Section 7.6.7.6.3
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
v2 of set to merge:
- Fixed blksize check in set dc region config
- Added check that it is a power of 2 (and host-ut
From: Anisa Su
FM DCD Management command 0x5604 implemented per CXL r3.2 Spec Section 7.6.7.6.5
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
include/hw/cxl/cxl_device.h | 4 ++
hw/cxl/cxl-mailbox-utils.c | 109
hw/mem
From: Anisa Su
FM DCD Management command 0x5603 implemented per CXL r3.2 Spec Section 7.6.7.6.4
Very similar to previously implemented command 0x4801.
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
v2 for merge:
- Added a missing : in a comment similar to Fan
From: Anisa Su
FM DCD Management command 0x5601 implemented per CXL r3.2 Spec Section 7.6.7.6.2
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-mailbox-utils.c | 106 +
1 file changed, 106 insertions(+)
diff --gi
From: Anisa Su
Move definition/enum to cxl_events.h for shared use in next patch
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
include/hw/cxl/cxl_events.h | 15 +++
hw/mem/cxl_type3.c | 15 ---
2 files changed, 15 insertions(
From: Anisa Su
Add booleans to DC Region struct to represent dsmas flags (defined in CDAT) in
preparation for the next command, which returns the flags in the next mailbox
command 0x5601.
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
v2 for merge
- Added some
From: Anisa Su
FM DCD Management command 0x5600 implemented per CXL 3.2 Spec Section 7.6.7.6.1.
Reviewed-by: Fan Ni
Signed-off-by: Anisa Su
Signed-off-by: Jonathan Cameron
---
v2 series for merge.
- Modify the code that fills in the support blk sizes to not
do effectively 2**log2(x) when we
From: Fan Ni
Per cxl r3.2 Section 9.13.3.3, extent capacity tracking should include
extents in different states including added, pending, etc.
Before the change, for the in-device extent number tracking purpose, we only
have "total_extent_count" defined, which only tracks the number of
extents a
v2:
- Missing colon and tags (Fan)
- Simpler handling block size parameters. The spec constrains these to
be power of 2 so the v1 code of BITUL((int)log2(x) is equivalent of
just using x directly. (Michael)
- Check for power of 2 (Fan + Anisa)
Hi Michael,
I consider these ready for upstream
From: Yicong Yang
Currently we build the PPTT starting from the socket node and each
socket will be a separate tree. For a multi-socket system it'll
be hard for the OS to know the whole system is homogeneous or not
(actually we're in the current implementation) since no parent node
to telling the
Update the ACPI tables according to the acpi aml_build change, also
empty bios-tables-test-allowed-diff.h.
The disassembled differences between actual and expected PPTT shows
below. Only about the root node adding and identification flag set
as expected.
Diff regarding Loongarch64:
/*
* Intel
From: Yicong Yang
Per ACPI 6.5 Table 5.158: Processor Structure Flags, the identical
implementation flag indicates whether all the children processors
of this node share the same identical implementation revision.
Currently Linux support parsing this field [1] and maybe used to
identify the heter
OS like Linux is using PPTT processor node's identical implementation
flag [1] to infer whether the whole system or a certain CPU cluster is
homogeneous or not [2]. QEMU currently only support building homogeneous
system, set the flag to indicate the fact. Build a root node in PPTT for
indicates th
From: Yicong Yang
Allow changes to PPTT test table, preparing for adding identical
implementation flags support and for adding a root node for all
the system.
This is related to both loongarch64 and aarch64.
Signed-off-by: Yicong Yang
Reviewed-by: Jonathan Cameron
Reviewed-by: Zhao Liu
Signe
On Mon, 14 Jul 2025 17:21:10 +
Anisa Su wrote:
> On Mon, Jul 14, 2025 at 06:02:26PM +0100, Jonathan Cameron wrote:
> > On Mon, 14 Jul 2025 09:45:31 -0700
> > Fan Ni wrote:
> >
> > > On Mon, Jul 14, 2025 at 03:16:38PM +0100, Jonathan Cameron wrote:
> > > > On Mon, 14 Jul 2025 15:15:12 +0
On Mon, 14 Jul 2025 09:45:31 -0700
Fan Ni wrote:
> On Mon, Jul 14, 2025 at 03:16:38PM +0100, Jonathan Cameron wrote:
> > On Mon, 14 Jul 2025 15:15:12 +0100
> > Jonathan Cameron wrote:
> >
> > > On Mon, 14 Jul 2025 15:02:18 +0100
> > > Jonathan Cameron wrote:
> > >
> > > > On Mon, 14 Jul 2
On Mon, Jul 14, 2025 at 04:59:30PM +0100, Shameer Kolothum wrote:
> Allows to retrieve the PCIIOMMUOps based on the SMMU type. This will be
> useful when we add support for accelerated SMMUV3 in subsequent patches
> as that requires a different set of callbacks for iommu ops.
>
> No special handli
On Mon, 14 Jul 2025 11:57:19 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Jul 14, 2025 at 03:10:41PM +0100, Alireza Sanaee wrote:
> > On Mon, 14 Jul 2025 09:09:10 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Jun 04, 2025 at 12:52:32PM +0100, Alireza Sanaee wrote:
> > > > From: Yic
Hi Shameer,
Thank you for sending the v3.
On Mon, Jul 14, 2025 at 04:59:26PM +0100, Shameer Kolothum wrote:
> Branch for testing:
[...]
> Tested on a HiSilicon platform with multiple SMMUv3s.
>
> ./qemu-system-aarch64 \
> -machine virt,accel=kvm,gic-version=3 \
> -object iommufd,id=iommufd0
From: Nicolin Chen
Not all fields in the SMMU IDR registers are meaningful for userspace.
Only the following fields can be used:
- IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16, TTF
- IDR1: SIDSIZE, SSIDSIZE
- IDR3: BBML, RIL
- IDR5: VAX, GRAN64K, GRAN16K, GRAN4K
(S2) mappings for guest RAM, while the guest
controls Stage-1 (S1). To allow VFIO to correctly configure S2 mappings,
we currently return the system address space via the get_address_space()
callback for vfio-pci devices.
However, QEMU/KVM also uses this same callback path when resolving the
From: Nicolin Chen
Use the provided smmuv3-accel helper functions to issue the
invalidation commands to host SMMUv3.
Signed-off-by: Nicolin Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3-internal.h | 11 +++
hw/arm/smmuv3.c | 28
2 files c
Also setup specific PCIIOMMUOps for accel SMMUv3 as accel
SMMUv3 will have different handling for those ops callbacks
in subsequent patches.
The "accel" property is not yet added, so users cannot set it at this
point. It will be introduced in a subsequent patch once the necessary
support is in pla
Allows to retrieve the PCIIOMMUOps based on the SMMU type. This will be
useful when we add support for accelerated SMMUV3 in subsequent patches
as that requires a different set of callbacks for iommu ops.
No special handling is required for now and returns the default ops
in base SMMU Class.
No f
On Mon, 14 Jul 2025 11:57:19 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Jul 14, 2025 at 03:10:41PM +0100, Alireza Sanaee wrote:
> > On Mon, 14 Jul 2025 09:09:10 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Jun 04, 2025 at 12:52:32PM +0100, Alireza Sanaee wrote:
> > > > From: Yic
Subsequent patches for smmuv3 accel support will make use of this.
Signed-off-by: Nicolin Chen
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
hw/arm/smmu-common.c | 48 ++--
include/hw/arm/smmu-common.h | 6 +
2 files changed, 36 insert
Hi All,
This patch series introduces initial support for a user-creatable,
accelerated SMMUv3 device (-device arm-smmuv3,accel=on) in QEMU.
This is based on the user-creatable SMMUv3 device series [0].
Why this is needed:
On ARM, to enable vfio-pci pass-through devices in a VM, the host SMMUv3
From: Nicolin Chen
Helpers will batch the commands and issue at once to host SMMUv3.
Signed-off-by: Nicolin Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3-accel.c| 65
hw/arm/smmuv3-accel.h| 16 ++
hw/arm/smmuv3-internal.h | 12
Now user can set "accel=on". Have fun!
Signed-off-by: Shameer Kolothum
---
hw/arm/smmu-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
index 6a58f574d3..3e8783670a 100644
--- a/hw/arm/smmu-common.c
+++ b/hw/arm/smmu-common.c
@@ -1022,6 +10
From: Nicolin Chen
Implement a set_iommu_device callback:
-If found an existing viommu reuse that.
(Devices behind the same physical SMMU should share an S2 HWPT)
-Else,
Allocate a viommu with the nested parent S2 hwpt allocated by VFIO.
Allocate bypass and abort hwpt.
-And add the
From: Nicolin Chen
Allocates a s1 HWPT for the Guest s1 stage and attaches that
to the dev. This will be invoked when Guest issues
SMMU_CMD_CFGI_STE/STE_RANGE.
While at it, we are also exporting both smmu_find_ste() and
smmuv3_flush_config() from smmuv3.c for use here.
Signed-off-by: Nicolin Ch
For accelerated SMMUv3, we need nested parent domain creation. Add the
callback support so that VFIO can create a nested parent.
Since 'accel=on' for SMMUv3 requires the guest SMMUv3 to be configured
in Stage 1 mode, ensure that the 'stage' property is explicitly set to
Stage 1.
Signed-off-by: Sh
From: Nicolin Chen
Allocate and associate a vDEVICE object for the Guest device
with the vIOMMU. This will help the kernel to do the
vSID --> sid translation whenever required (eg: device specific
invalidations).
Signed-off-by: Nicolin Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3-ac
From: Nicolin Chen
Add a helper to allocate a viommu object.
Signed-off-by: Nicolin Chen
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
backends/iommufd.c | 25 +
backends/trace-events| 1 +
include/system/iommufd.h | 4
3 files changed,
able correct S2 mappings of guest RAM.
So in short:
- vfio-pci devices return the system address space
- bridges and root ports return the IOMMU address space
Note: On ARM, MSI doorbell addresses are also translated via SMMUv3.
Hence, if a vfio-pci device is behind the SMMuv3 with translation e
From: Nicolin Chen
Add a helper to allocate an iommufd device's virtual device (in the user
space) per a viommu instance.
Signed-off-by: Nicolin Chen
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
backends/iommufd.c | 26 ++
backends/trace-events
On Mon, 14 Jul 2025 15:02:18 +0100
Jonathan Cameron wrote:
> On Mon, 14 Jul 2025 05:32:19 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Jul 02, 2025 at 05:02:13PM +0100, Jonathan Cameron wrote:
> > > From: Anisa Su
> > >
> > > FM DCD Management command 0x5602 implemented per CXL r3.2 Sp
On Mon, 14 Jul 2025 15:15:12 +0100
Jonathan Cameron wrote:
> On Mon, 14 Jul 2025 15:02:18 +0100
> Jonathan Cameron wrote:
>
> > On Mon, 14 Jul 2025 05:32:19 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Jul 02, 2025 at 05:02:13PM +0100, Jonathan Cameron wrote:
> > > > From: An
On Mon, 14 Jul 2025 09:09:10 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Jun 04, 2025 at 12:52:32PM +0100, Alireza Sanaee wrote:
> > From: Yicong Yang
> >
> > Currently we build the PPTT starting from the socket node and each
> > socket will be a separate tree. For a multi-socket system it'll
>
On Mon, 14 Jul 2025 05:32:19 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Jul 02, 2025 at 05:02:13PM +0100, Jonathan Cameron wrote:
> > From: Anisa Su
> >
> > FM DCD Management command 0x5602 implemented per CXL r3.2 Spec Section
> > 7.6.7.6.3
> >
> > Reviewed-by: Fan Ni
> > Signed-off-by: An
On Mon, 14 Jul 2025 06:11:44 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Jul 14, 2025 at 10:59:58AM +0100, Alireza Sanaee wrote:
> > On Sun, 13 Jul 2025 17:15:02 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Mon, Jul 07, 2025 at 01:19:06PM +0100, Alireza Sanaee wrote:
> > > > Add cache
On Sun, 13 Jul 2025 17:15:02 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Jul 07, 2025 at 01:19:06PM +0100, Alireza Sanaee wrote:
> > Add cache topology to PPTT table. With this patch, both ACPI PPTT
> > table and device tree will represent the same cache topology given
> > users input.
> >
> > C
> -Original Message-
> From: Nicolin Chen
> Sent: Thursday, July 10, 2025 6:16 PM
> To: Shameerali Kolothum Thodi
> Cc: Donald Dutile ; Zhenzhong Duan
> ; qemu-devel@nongnu.org;
> alex.william...@redhat.com; c...@redhat.com; eric.au...@redhat.com;
> m...@redhat.com; jasow...@redhat.com
Hey Ilya,
On 7/9/25 2:29 PM, Ilya Maximets wrote:
[...]
Thnaks, Daniel! I have just a couple of small nits below that I missed in v3,
the rest looks good and is working fine.
diff --git a/net/af-xdp.c b/net/af-xdp.c
index 29c5ad16cd..005117c336 100644
--- a/net/af-xdp.c
+++ b/net/af-xdp.c
@@
1 - 100 of 2774 matches
Mail list logo
