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
On ARM, when a device is behind an IOMMU, its MSI doorbell address is
subject to translation by the IOMMU. This behavior affects vfio-pci
passthrough devices assigned to guests using an accelerated SMMUv3.
In this setup, we configure the host SMMUv3 in nested mode, where
VFIO sets up the Stage-2 (
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
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,
Accelerated SMMUv3 is only useful when the device can take advantage of
the host's SMMUv3 in nested mode. To keep things simple and correct, we
only allow this feature for vfio-pci endpoint devices that use the iommufd
backend. We also allow non-endpoint emulated devices like PCI bridges and
root p
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
For the legacy smmuv3 test case, generated IORT has a single SMMUv3 node,
a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones points to ITS.
pcie.0 -> {SMMU0} -> {ITS}
{RC} pcie.1 -> {SMMU0} -> {ITS}
pcie.2
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
i
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +
For the legacy SMMUv3 test, the setup includes three PCIe Root Complexes,
one of which has bypass_iommu enabled. The generated IORT table contains
a single SMMUv3 node, a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones poin
Introduce a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have com
The tests to be added exercise both legacy(iommu=smmuv3) and new
-device arm-smmuv3,.. cases.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev| 0
tests/data/acpi/aarch64/virt/DSDT.
Changes from v7:
https://lore.kernel.org/qemu-devel/20250708154055.101012-1-shameerali.kolothum.th...@huawei.com/
1. Rebased to latest target-arm.next(I have included patch#1
as I can't find that after a git pull of latest)
2. Addressed comments from Nicolin and added R-by tags. Thanks!
Hi Pet
Allow cold-plugging of an SMMUv3 device on the virt machine when no
global (legacy) SMMUv3 is present or when a virtio-iommu is specified.
This user-created SMMUv3 device is tied to a specific PCI bus provided
by the user, so ensure the IOMMU ops are configured accordingly.
Due to current limitat
Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus.
However, when retrieving IOMMU ops for a device using
pci_device_get_iommu_bus_devfn(), the function checks the parent_dev
and fetches IOMMU ops from the parent device, even if the current
bus does not have any associated IOMMU op
We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
root complexes to be associated with SMMU.
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Note: Added a specific check to
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
An example IORT Id mappings for a Qemu virt machine with two
PCIe Root Complexes each assocaited with
Commit d6afe18b7242 ("hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables
when its=off") moved ITS group node generation under the its=on condition.
However, it still creates rc_its_idmaps unconditionally, which results in
duplicate ID mappings in the IORT table.
Fixes:d6afe18b7242 ("hw/arm/virt
Allow cold-plugging of an SMMUv3 device on the virt machine when no
global (legacy) SMMUv3 is present or when a virtio-iommu is specified.
This user-created SMMUv3 device is tied to a specific PCI bus provided
by the user, so ensure the IOMMU ops are configured accordingly.
Due to current limitat
The tests to be added exercise both legacy(iommu=smmuv3) and new
-device arm-smmuv3,.. cases.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev| 0
tests/data/acpi/aarch64/virt/DSDT.
We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
root complexes to be associated with SMMU.
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Note: Added a specific check to
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
i
Introduce a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have com
For the legacy SMMUv3 test, the setup includes three PCIe Root Complexes,
one of which has bypass_iommu enabled. The generated IORT table contains
a single SMMUv3 node, a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones poin
For the legacy smmuv3 test case, generated IORT has a single SMMUv3 node,
a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones points to ITS.
pcie.0 -> {SMMU0} -> {ITS}
{RC} pcie.1 -> {SMMU0} -> {ITS}
pcie.2
Commit d6afe18b7242 ("hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables
when its=off") moved ITS group node generation under the its=on condition.
However, it still creates rc_its_idmaps unconditionally, which results in
duplicate ID mappings in the IORT table.
Fixes:d6afe18b7242 ("hw/arm/virt
Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus.
However, when retrieving IOMMU ops for a device using
pci_device_get_iommu_bus_devfn(), the function checks the parent_dev
and fetches IOMMU ops from the parent device, even if the current
bus does not have any associated IOMMU op
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Tested-by: Eric Auger
Signed-off-by: Shameer Kolothum
Hi All,
Changes from v6:
https://lore.kernel.org/qemu-devel/20250703084643.85740-1-shameerali.kolothum.th...@huawei.com/
1. Fixed the warning case for DT support, reported by Eric(patch #8).
2. Picked up R-by's and T-by's. Thanks!
Please take a look and let me know. I think this is in a good sha
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
An example IORT Id mappings for a Qemu virt machine with two
PCIe Root Complexes each assocaited with
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
An example IORT Id mappings for a Qemu virt machine with two
PCIe Root Complexes each assocaited with
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index 1f862b19a6..17d517
For the legacy smmuv3 test case, generated IORT has a single SMMUv3 node,
a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones points to ITS.
pcie.0 -> {SMMU0} -> {ITS}
{RC} pcie.1 -> {SMMU0} -> {ITS}
pcie.2
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 5
For the legacy SMMUv3 test, the setup includes three PCIe Root Complexes,
one of which has bypass_iommu enabled. The generated IORT table contains
a single SMMUv3 node, a Root Complex(RC) node and 1 ITS node.
RC node features 4 ID mappings, of which 2 points to SMMU node and the
remaining ones poin
Introduce a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have com
Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus.
However, when retrieving IOMMU ops for a device using
pci_device_get_iommu_bus_devfn(), the function checks the parent_dev
and fetches IOMMU ops from the parent device, even if the current
bus does not have any associated IOMMU op
Allow cold-plugging of an SMMUv3 device on the virt machine when no
global (legacy) SMMUv3 is present or when a virtio-iommu is specified.
This user-created SMMUv3 device is tied to a specific PCI bus provided
by the user, so ensure the IOMMU ops are configured accordingly.
Due to current limitat
The tests to be added exercise both legacy(iommu=smmuv3) and new
-device arm-smmuv3,.. cases.
Reviewed-by: Jonathan Cameron
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev| 0
tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy | 0
test
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +++-
We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
root complexes to be associated with SMMU.
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Note: Added a specific check to
Hi All,
Changes from v5:
https://lore.kernel.org/qemu-devel/20250623094230.76084-1-shameerali.kolothum.th...@huawei.com/
1. Rebased to target-arm.next and resolved conflicts with the series
[PATCH-for-10.1 v6 0/9] hw/arm: GIC 'its=off'.
2. While at it, noticed an issue with RC id mappings cre
Commit d6afe18b7242 ("hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables
when its=off") moved ITS group node generation under the its=on condition.
However, it still creates rc_its_idmaps unconditionally, which results in
duplicate ID mappings in the IORT table.
Fixes:d6afe18b7242 ("hw/arm/virt
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
An example IORT Id mappings for a Qemu virt machine with two
PCIe Root Complexes each assocaited with
We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
root complexes to be associated with SMMU.
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Signed-off-by: Shameer Kolothum
Introduce a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have com
For the legacy smmuv3 test case, IORT has a single SMMUV3 node and
a Root Complex node with three ID mappings of which two points to
the SMMUv3 node and the remaining one points to ITS.
...
[030h 0048 1] Type : 00
[031h 0049 2] Length : 0018
[033h
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Reviewed-by: Jonathan Cameron
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +++-
For the legacy SMMUv3 test, the setup includes three PCIe Root Complexes,
one of which has bypass_iommu enabled. The generated IORT table contains
a single SMMUv3 node and a Root Complex node with three ID mappings. Two
of these ID mappings have output references pointing to the SMMUv3 node
and the
The tests to be added exercises both legacy(iommu=smmuv3) and new
-device arm-smmuv3,.. cases.
Signed-off-by: Shameer Kolothum
---
tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev| 0
tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy | 0
tests/data/acpi/aarch64/virt/IORT.smmuv3-dev| 0
tests/
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7eb8e02b4b..7d1a12f7ef 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus.
However, when retrieving IOMMU ops for a device using
pci_device_get_iommu_bus_devfn(), the function checks the parent_dev
and fetches IOMMU ops from the parent device, even if the current
bus does not have any associated IOMMU op
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 5 -
1 file changed, 4 insert
Allow cold-plugging of an SMMUv3 device on the virt machine when no
global (legacy) SMMUv3 is present or when a virtio-iommu is specified.
This user-created SMMUv3 device is tied to a specific PCI bus provided
by the user, so ensure the IOMMU ops are configured accordingly.
Due to current limitat
Hi All,
Changes from v4:
https://lore.kernel.org/qemu-devel/2025061319.60156-1-shameerali.kolothum.th...@huawei.com/
Major changes from v4:
1. Added stricter validation for PCI buses associated with the SMMU.
Only the default PCIe Root Complex (pcie.0) and additional root
complexes cre
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 6 ++
1 file changed, 6 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7eb8e02b4b..3edbde45bb 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@
Hi All,
Changes from v3:
https://lore.kernel.org/qemu-devel/20250602154110.48392-1-shameerali.kolothum.th...@huawei.com/
Addressed feedback on v3. Thanks to all.
Major changes:
1. Based on Igor's suggestion, moved the associated primary-bus is of type
TYPE_PCI_HOST_BRIDGE check to smmu-common.
Allow cold-plug of smmuv3 device to virt if there is no machine
wide legacy smmuv3 or a virtio-iommu is specified.
Device tree support for new smmuv3 dev is limited to the case where
it is associated with the default pcie.0 RC.
Tested-by: Nathan Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Tested-by: Nathan Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/smmu-common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
An example IORT Id mappings for a Qemu virt machine with two
PCIe Root Complexes each assocaited with
Introduces a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have co
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +++
1 file
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Tested-by: Nathan Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 8 +---
1 file changed, 5 ins
Allow cold-plug of smmuv3 device to virt if there is no machine
wide legacy smmuv3 or a virtio-iommu is specified.
Device tree support for new smmuv3 dev is limited to the case where
it is associated with the default pcie.0 RC.
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 2 ++
h
Although this change does not affect functionality at present, it is
required when we add support for user-creatable SMMUv3 devices in
future patches.
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
Introduces a new struct AcpiIortSMMUv3Dev to hold all the information
required for SMMUv3 IORT node and use that for populating the node.
The current machine wide SMMUv3 is named as legacy SMMUv3 as we will
soon add support for user-creatable SMMUv3 devices. These changes will
be useful to have co
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +++
1 file changed, 29 insertions(
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Reviewed-by: Donald Dutile
Reviewed-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt-acpi-build.c | 54 +
Hi All,
Changes from v2:
https://lore.kernel.org/qemu-devel/20250502102707.110516-1-shameerali.kolothum.th...@huawei.com/
Addressed feedback on v2. Thanks to all.
Major changes:
1. Not use the default "bus" property for associated PCIe RC.
Instead use "primary-bus".
2. Split of IORT ACPI chang
default_bus_bypass_iommu tells us whether the bypass_iommu is set
for the default PCIe root bus. Make sure we check that before adding
the "iommu-map" DT property.
Fixes: 6d7a85483a06 ("hw/arm/virt: Add default_bus_bypass_iommu machine option")
Suggested-by: Eric Auger
Signed-off-by: Shameer Kolo
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 54 +++
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/hw/arm/virt.c b/hw
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt-acpi-build.c | 162 +++-
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 605de9b721..e13950b7c5 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -2022,6 +2022,7 @@ static void smmuv3_class_init(ObjectClass *klass, const
Although this change does not affect functionality at present, it lays
the groundwork for enabling user-created SMMUv3 devices in
future patches
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 26 ++
hw/arm/virt.c | 3 ++-
2 files changed, 28 insertions(+), 1 del
From: Nicolin Chen
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index
Allow cold-plug of smmuv3 device to virt if there is no machine
wide legacy smmuv3 or a virtio-iommu is specified.
Device tree support for new smmuv3 dev is limited to the case where
it is associated with the default pcie.0 RC.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c| 48 +
Hi All,
Changes from v1:
https://lore.kernel.org/qemu-devel/20250415081104.71708-1-shameerali.kolothum.th...@huawei.com/
Addressed feedback on v1. Thanks to all.
1. Retained the same name as the legacy SMMUv3(arm-smmuv3) for new
device type as well (instead of arm-smmuv3-dev type usage in v1).
Allow cold-plug of smmuv3 device to virt If the machine wide smmuv3
or a virtio-iommu is not specified.
Also restrict the usage if virt <= 9.2. This will prevent accidently
creating a SMMUv3 device on machines prior to 9.2 and cause failure
on migrating to machines with same version but has a lega
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index e3b8e13ca3..572119e472 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -2026,6 +2026,7 @@ static void smmuv3_dev_class_init(ObjectClass *klass,
vo
With the soon to be introduced user-creatable SMMUv3 devices for
virt, it is possible to have multiple SMMUv3 devices associated
with different PCIe root complexes.
Update IORT nodes accordingly.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt-acpi-build.c | 119
Hi All,
This patch series introduces support for a user-creatable SMMUv3 device
(-device arm-smmuv3-dev) in QEMU.
The implementation is based on feedback received from the RFCv2[0]:
"hw/arm/virt: Add support for user-creatable accelerated SMMUv3"
Currently, QEMU's SMMUv3 emulation (iommu=smmuv3)
Initial support to have a user-creatable SMMUv3 device associated
with a PCIe root complex,
-device arm-smmuv3-dev,bus=pcie.x
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 54 +
include/hw/arm/smmuv3.h | 16
2 files changed, 7
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Signed-off-by: Shameer Kolothum
---
hw/arm/virt.c | 55 +++
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/hw/arm/virt.c b/hw
Based on SMMUv3 as a parent device, add a user-creatable smmuv3-accel
device. In order to support vfio-pci dev assignment with a Guest
SMMUv3, the physical SMMUv3 has to be configured in nested(S1+s2)
mode, with Guest owning the S1 page tables. Subsequent patches will
add support for smmuv3-accel t
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3-accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
index fb08e1d66b..812f8e358f 100644
--- a/hw/arm/smmuv3-accel.c
+++ b/hw/arm/smmuv3-accel.c
@@ -595,6 +595,7 @@ static void smmuv3_accel_clas
Make use of smmuv3_accel provided _install_nested_ste() for CFGI_STE.
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index ea63731d61..83159db1d4 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -12
From: Nicolin Chen
If a vSMMU is configured as a accelerated one, HW IOTLB will be used
and all cache invalidation should be done to the HW IOTLB too, v.s.
the emulated iotlb. In this case, an iommu notifier isn't registered,
as the devices behind a SMMUv3-accel would stay in the system address
s
1 - 100 of 149 matches
Mail list logo
