* [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:32 ` Jonathan Cameron via
2025-06-27 11:52 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build Shameer Kolothum via
` (11 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/smmu-common.c | 29 ++++++++++++++++++++++++++---
hw/pci-bridge/pci_expander_bridge.c | 1 -
include/hw/pci/pci_bridge.h | 1 +
3 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
index f39b99e526..b15e7fd0e4 100644
--- a/hw/arm/smmu-common.c
+++ b/hw/arm/smmu-common.c
@@ -20,6 +20,7 @@
#include "trace.h"
#include "exec/target_page.h"
#include "hw/core/cpu.h"
+#include "hw/pci/pci_bridge.h"
#include "hw/qdev-properties.h"
#include "qapi/error.h"
#include "qemu/jhash.h"
@@ -925,6 +926,7 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
{
SMMUState *s = ARM_SMMU(dev);
SMMUBaseClass *sbc = ARM_SMMU_GET_CLASS(dev);
+ PCIBus *pci_bus = s->primary_bus;
Error *local_err = NULL;
sbc->parent_realize(dev, &local_err);
@@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
g_free, g_free);
s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL);
- if (s->primary_bus) {
- pci_setup_iommu(s->primary_bus, &smmu_ops, s);
- } else {
+ if (!pci_bus) {
error_setg(errp, "SMMU is not attached to any PCI bus!");
+ return;
+ }
+
+ /*
+ * We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
+ * root complexes to be associated with SMMU.
+ */
+ if (pci_bus_is_express(pci_bus) && pci_bus_is_root(pci_bus) &&
+ object_dynamic_cast(OBJECT(pci_bus)->parent, TYPE_PCI_HOST_BRIDGE)) {
+ /*
+ * For pxb-pcie, parent_dev will be set. Make sure it is
+ * pxb-pcie indeed.
+ */
+ if (pci_bus->parent_dev) {
+ if (!object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)) {
+ goto out_err;
+ }
+ }
+ pci_setup_iommu(pci_bus, &smmu_ops, s);
+ return;
}
+out_err:
+ error_setg(errp, "SMMU should be attached to a default PCIe root complex"
+ "(pcie.0) or a pxb-pcie based root complex");
}
/*
diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c
index 3a29dfefc2..1bcceddbc4 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -34,7 +34,6 @@ typedef struct PXBBus PXBBus;
DECLARE_INSTANCE_CHECKER(PXBBus, PXB_BUS,
TYPE_PXB_BUS)
-#define TYPE_PXB_PCIE_BUS "pxb-pcie-bus"
DECLARE_INSTANCE_CHECKER(PXBBus, PXB_PCIE_BUS,
TYPE_PXB_PCIE_BUS)
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index b0f5204d80..de0eba55b7 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -104,6 +104,7 @@ typedef struct PXBPCIEDev {
PXBDev parent_obj;
} PXBPCIEDev;
+#define TYPE_PXB_PCIE_BUS "pxb-pcie-bus"
#define TYPE_PXB_CXL_BUS "pxb-cxl-bus"
#define TYPE_PXB_DEV "pxb"
OBJECT_DECLARE_SIMPLE_TYPE(PXBDev, PXB_DEV)
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
2025-06-23 9:42 ` [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
@ 2025-06-23 11:32 ` Jonathan Cameron via
2025-06-27 11:52 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:32 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:20 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 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 <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
2025-06-23 9:42 ` [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
2025-06-23 11:32 ` Jonathan Cameron via
@ 2025-06-27 11:52 ` Eric Auger
2025-06-30 7:01 ` Shameerali Kolothum Thodi via
1 sibling, 1 reply; 39+ messages in thread
From: Eric Auger @ 2025-06-27 11:52 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
Hi Shameer,
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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 <shameerali.kolothum.thodi@huawei.com>
> ---
> hw/arm/smmu-common.c | 29 ++++++++++++++++++++++++++---
> hw/pci-bridge/pci_expander_bridge.c | 1 -
> include/hw/pci/pci_bridge.h | 1 +
> 3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
> index f39b99e526..b15e7fd0e4 100644
> --- a/hw/arm/smmu-common.c
> +++ b/hw/arm/smmu-common.c
> @@ -20,6 +20,7 @@
> #include "trace.h"
> #include "exec/target_page.h"
> #include "hw/core/cpu.h"
> +#include "hw/pci/pci_bridge.h"
> #include "hw/qdev-properties.h"
> #include "qapi/error.h"
> #include "qemu/jhash.h"
> @@ -925,6 +926,7 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
> {
> SMMUState *s = ARM_SMMU(dev);
> SMMUBaseClass *sbc = ARM_SMMU_GET_CLASS(dev);
> + PCIBus *pci_bus = s->primary_bus;
> Error *local_err = NULL;
>
> sbc->parent_realize(dev, &local_err);
> @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
> g_free, g_free);
> s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL);
>
> - if (s->primary_bus) {
> - pci_setup_iommu(s->primary_bus, &smmu_ops, s);
> - } else {
> + if (!pci_bus) {
> error_setg(errp, "SMMU is not attached to any PCI bus!");
> + return;
> + }
> +
> + /*
> + * We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra
> + * root complexes to be associated with SMMU.
> + */
> + if (pci_bus_is_express(pci_bus) && pci_bus_is_root(pci_bus) &&
> + object_dynamic_cast(OBJECT(pci_bus)->parent, TYPE_PCI_HOST_BRIDGE)) {
> + /*
> + * For pxb-pcie, parent_dev will be set. Make sure it is
> + * pxb-pcie indeed.
> + */
> + if (pci_bus->parent_dev) {
> + if (!object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)) {
> + goto out_err;
> + }
I still wonder whether the above check was mandated as it works for what
it is meant:
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
> + }
> + pci_setup_iommu(pci_bus, &smmu_ops, s);
> + return;
> }
> +out_err:
> + error_setg(errp, "SMMU should be attached to a default PCIe root complex"
> + "(pcie.0) or a pxb-pcie based root complex");
> }
>
> /*
> diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c
> index 3a29dfefc2..1bcceddbc4 100644
> --- a/hw/pci-bridge/pci_expander_bridge.c
> +++ b/hw/pci-bridge/pci_expander_bridge.c
> @@ -34,7 +34,6 @@ typedef struct PXBBus PXBBus;
> DECLARE_INSTANCE_CHECKER(PXBBus, PXB_BUS,
> TYPE_PXB_BUS)
>
> -#define TYPE_PXB_PCIE_BUS "pxb-pcie-bus"
> DECLARE_INSTANCE_CHECKER(PXBBus, PXB_PCIE_BUS,
> TYPE_PXB_PCIE_BUS)
>
> diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
> index b0f5204d80..de0eba55b7 100644
> --- a/include/hw/pci/pci_bridge.h
> +++ b/include/hw/pci/pci_bridge.h
> @@ -104,6 +104,7 @@ typedef struct PXBPCIEDev {
> PXBDev parent_obj;
> } PXBPCIEDev;
>
> +#define TYPE_PXB_PCIE_BUS "pxb-pcie-bus"
> #define TYPE_PXB_CXL_BUS "pxb-cxl-bus"
> #define TYPE_PXB_DEV "pxb"
> OBJECT_DECLARE_SIMPLE_TYPE(PXBDev, PXB_DEV)
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
2025-06-27 11:52 ` Eric Auger
@ 2025-06-30 7:01 ` Shameerali Kolothum Thodi via
2025-07-01 6:31 ` Eric Auger
0 siblings, 1 reply; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-06-30 7:01 UTC (permalink / raw)
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
Hi Eric,
> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, June 27, 2025 12:52 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has
> PCIe Root Complex association
>
> Hi Shameer,
>
> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> > 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
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> > hw/arm/smmu-common.c | 29 ++++++++++++++++++++++++++---
> > hw/pci-bridge/pci_expander_bridge.c | 1 -
> > include/hw/pci/pci_bridge.h | 1 +
> > 3 files changed, 27 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
> > index f39b99e526..b15e7fd0e4 100644
> > --- a/hw/arm/smmu-common.c
> > +++ b/hw/arm/smmu-common.c
> > @@ -20,6 +20,7 @@
> > #include "trace.h"
> > #include "exec/target_page.h"
> > #include "hw/core/cpu.h"
> > +#include "hw/pci/pci_bridge.h"
> > #include "hw/qdev-properties.h"
> > #include "qapi/error.h"
> > #include "qemu/jhash.h"
> > @@ -925,6 +926,7 @@ static void smmu_base_realize(DeviceState *dev,
> Error **errp)
> > {
> > SMMUState *s = ARM_SMMU(dev);
> > SMMUBaseClass *sbc = ARM_SMMU_GET_CLASS(dev);
> > + PCIBus *pci_bus = s->primary_bus;
> > Error *local_err = NULL;
> >
> > sbc->parent_realize(dev, &local_err);
> > @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState
> *dev, Error **errp)
> > g_free, g_free);
> > s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL);
> >
> > - if (s->primary_bus) {
> > - pci_setup_iommu(s->primary_bus, &smmu_ops, s);
> > - } else {
> > + if (!pci_bus) {
> > error_setg(errp, "SMMU is not attached to any PCI bus!");
> > + return;
> > + }
> > +
> > + /*
> > + * We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based
> extra
> > + * root complexes to be associated with SMMU.
> > + */
> > + if (pci_bus_is_express(pci_bus) && pci_bus_is_root(pci_bus) &&
> > + object_dynamic_cast(OBJECT(pci_bus)->parent,
> TYPE_PCI_HOST_BRIDGE)) {
> > + /*
> > + * For pxb-pcie, parent_dev will be set. Make sure it is
> > + * pxb-pcie indeed.
> > + */
> > + if (pci_bus->parent_dev) {
> > + if (!object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)) {
> > + goto out_err;
> > + }
> I still wonder whether the above check was mandated as it works for what
> it is meant:
Added that check to make sure we don't support pxb-cxl which is of type
PCI_HOST_BRIDGE. Once the cxl support for ARM is up streamed and tested
with SMMUv3, we can relax this if required.
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks,
Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
2025-06-30 7:01 ` Shameerali Kolothum Thodi via
@ 2025-07-01 6:31 ` Eric Auger
0 siblings, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-07-01 6:31 UTC (permalink / raw)
To: Shameerali Kolothum Thodi, qemu-arm@nongnu.org,
qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
On 6/30/25 9:01 AM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Friday, June 27, 2025 12:52 PM
>> To: Shameerali Kolothum Thodi
>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>> qemu-devel@nongnu.org
>> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
>> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
>> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
>> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
>> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
>> Jonathan Cameron <jonathan.cameron@huawei.com>;
>> zhangfei.gao@linaro.org
>> Subject: Re: [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has
>> PCIe Root Complex association
>>
>> Hi Shameer,
>>
>> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
>>> 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
>> <shameerali.kolothum.thodi@huawei.com>
>>> ---
>>> hw/arm/smmu-common.c | 29 ++++++++++++++++++++++++++---
>>> hw/pci-bridge/pci_expander_bridge.c | 1 -
>>> include/hw/pci/pci_bridge.h | 1 +
>>> 3 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
>>> index f39b99e526..b15e7fd0e4 100644
>>> --- a/hw/arm/smmu-common.c
>>> +++ b/hw/arm/smmu-common.c
>>> @@ -20,6 +20,7 @@
>>> #include "trace.h"
>>> #include "exec/target_page.h"
>>> #include "hw/core/cpu.h"
>>> +#include "hw/pci/pci_bridge.h"
>>> #include "hw/qdev-properties.h"
>>> #include "qapi/error.h"
>>> #include "qemu/jhash.h"
>>> @@ -925,6 +926,7 @@ static void smmu_base_realize(DeviceState *dev,
>> Error **errp)
>>> {
>>> SMMUState *s = ARM_SMMU(dev);
>>> SMMUBaseClass *sbc = ARM_SMMU_GET_CLASS(dev);
>>> + PCIBus *pci_bus = s->primary_bus;
>>> Error *local_err = NULL;
>>>
>>> sbc->parent_realize(dev, &local_err);
>>> @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState
>> *dev, Error **errp)
>>> g_free, g_free);
>>> s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL);
>>>
>>> - if (s->primary_bus) {
>>> - pci_setup_iommu(s->primary_bus, &smmu_ops, s);
>>> - } else {
>>> + if (!pci_bus) {
>>> error_setg(errp, "SMMU is not attached to any PCI bus!");
>>> + return;
>>> + }
>>> +
>>> + /*
>>> + * We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based
>> extra
>>> + * root complexes to be associated with SMMU.
>>> + */
>>> + if (pci_bus_is_express(pci_bus) && pci_bus_is_root(pci_bus) &&
>>> + object_dynamic_cast(OBJECT(pci_bus)->parent,
>> TYPE_PCI_HOST_BRIDGE)) {
>>> + /*
>>> + * For pxb-pcie, parent_dev will be set. Make sure it is
>>> + * pxb-pcie indeed.
>>> + */
>>> + if (pci_bus->parent_dev) {
>>> + if (!object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)) {
>>> + goto out_err;
>>> + }
>> I still wonder whether the above check was mandated as it works for what
>> it is meant:
> Added that check to make sure we don't support pxb-cxl which is of type
> PCI_HOST_BRIDGE. Once the cxl support for ARM is up streamed and tested
> with SMMUv3, we can relax this if required.
agreed. I would add this in the commit msg while rebasing.
Eric
>
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Thanks,
> Shameer
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
2025-06-23 9:42 ` [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-27 11:54 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 03/11] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices Shameer Kolothum via
` (10 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 common code paths when we add that support.
Tested-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/virt-acpi-build.c | 109 +++++++++++++++++++++++++++------------
hw/arm/virt.c | 1 +
include/hw/arm/virt.h | 1 +
3 files changed, 77 insertions(+), 34 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 7e8e0f0298..28489cf59f 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -266,6 +266,34 @@ static int iort_idmap_compare(gconstpointer a, gconstpointer b)
return idmap_a->input_base - idmap_b->input_base;
}
+typedef struct AcpiIortSMMUv3Dev {
+ int irq;
+ hwaddr base;
+ GArray *idmaps;
+ /* Offset of the SMMUv3 IORT Node relative to the start of the IORT */
+ size_t offset;
+} AcpiIortSMMUv3Dev;
+
+static void populate_smmuv3_legacy_dev(GArray *sdev_blob)
+{
+ VirtMachineState *vms = VIRT_MACHINE(qdev_get_machine());
+ AcpiIortSMMUv3Dev sdev;
+
+ sdev.idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
+ object_child_foreach_recursive(object_get_root(), iort_host_bridges,
+ sdev.idmaps);
+ /*
+ * There can be only one legacy SMMUv3("iommu=smmuv3") as it is a machine
+ * wide one. Since it may cover multiple PCIe RCs(based on "bypass_iommu"
+ * property), may have multiple SMMUv3 idmaps. Sort it by input_base.
+ */
+ g_array_sort(sdev.idmaps, iort_idmap_compare);
+
+ sdev.base = vms->memmap[VIRT_SMMU].base;
+ sdev.irq = vms->irqmap[VIRT_SMMU] + ARM_SPI_BASE;
+ g_array_append_val(sdev_blob, sdev);
+}
+
/*
* Input Output Remapping Table (IORT)
* Conforms to "IO Remapping Table System Software on ARM Platforms",
@@ -274,11 +302,12 @@ static int iort_idmap_compare(gconstpointer a, gconstpointer b)
static void
build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
{
- int i, nb_nodes, rc_mapping_count;
- size_t node_size, smmu_offset = 0;
- AcpiIortIdMapping *idmap;
+ int i, j, nb_nodes, rc_mapping_count;
+ AcpiIortSMMUv3Dev *sdev;
+ size_t node_size;
+ int num_smmus = 0;
uint32_t id = 0;
- GArray *smmu_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
+ GArray *smmuv3_devs = g_array_new(false, true, sizeof(AcpiIortSMMUv3Dev));
GArray *its_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
AcpiTable table = { .sig = "IORT", .rev = 3, .oem_id = vms->oem_id,
@@ -286,28 +315,32 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
/* Table 2 The IORT */
acpi_table_begin(&table, table_data);
- if (vms->iommu == VIRT_IOMMU_SMMUV3) {
- AcpiIortIdMapping next_range = {0};
-
- object_child_foreach_recursive(object_get_root(),
- iort_host_bridges, smmu_idmaps);
-
- /* Sort the smmu idmap by input_base */
- g_array_sort(smmu_idmaps, iort_idmap_compare);
+ nb_nodes = 2; /* RC, ITS */
+ if (vms->legacy_smmuv3_present) {
+ populate_smmuv3_legacy_dev(smmuv3_devs);
+ }
+ num_smmus = smmuv3_devs->len;
+ if (num_smmus) {
+ AcpiIortIdMapping next_range = {0};
+ int smmu_map_cnt = 0;
/*
* Split the whole RIDs by mapping from RC to SMMU,
* build the ID mapping from RC to ITS directly.
*/
- for (i = 0; i < smmu_idmaps->len; i++) {
- idmap = &g_array_index(smmu_idmaps, AcpiIortIdMapping, i);
-
- if (next_range.input_base < idmap->input_base) {
- next_range.id_count = idmap->input_base - next_range.input_base;
- g_array_append_val(its_idmaps, next_range);
+ for (i = 0; i < num_smmus; i++) {
+ sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
+ for (j = 0; j < sdev->idmaps->len; j++) {
+ AcpiIortIdMapping *idmap = &g_array_index(sdev->idmaps,
+ AcpiIortIdMapping, j);
+ if (next_range.input_base < idmap->input_base) {
+ next_range.id_count = idmap->input_base -
+ next_range.input_base;
+ g_array_append_val(its_idmaps, next_range);
+ }
+ next_range.input_base = idmap->input_base + idmap->id_count;
+ smmu_map_cnt++;
}
-
- next_range.input_base = idmap->input_base + idmap->id_count;
}
/* Append the last RC -> ITS ID mapping */
@@ -316,10 +349,9 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
g_array_append_val(its_idmaps, next_range);
}
- nb_nodes = 3; /* RC, ITS, SMMUv3 */
- rc_mapping_count = smmu_idmaps->len + its_idmaps->len;
+ nb_nodes += num_smmus;
+ rc_mapping_count = smmu_map_cnt + its_idmaps->len;
} else {
- nb_nodes = 2; /* RC, ITS */
rc_mapping_count = 1;
}
/* Number of IORT Nodes */
@@ -341,10 +373,11 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
/* GIC ITS Identifier Array */
build_append_int_noprefix(table_data, 0 /* MADT translation_id */, 4);
- if (vms->iommu == VIRT_IOMMU_SMMUV3) {
- int irq = vms->irqmap[VIRT_SMMU] + ARM_SPI_BASE;
+ for (i = 0; i < num_smmus; i++) {
+ sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
+ int irq = sdev->irq;
- smmu_offset = table_data->len - table.table_offset;
+ sdev->offset = table_data->len - table.table_offset;
/* Table 9 SMMUv3 Format */
build_append_int_noprefix(table_data, 4 /* SMMUv3 */, 1); /* Type */
node_size = SMMU_V3_ENTRY_SIZE + ID_MAPPING_ENTRY_SIZE;
@@ -355,7 +388,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
/* Reference to ID Array */
build_append_int_noprefix(table_data, SMMU_V3_ENTRY_SIZE, 4);
/* Base address */
- build_append_int_noprefix(table_data, vms->memmap[VIRT_SMMU].base, 8);
+ build_append_int_noprefix(table_data, sdev->base, 8);
/* Flags */
build_append_int_noprefix(table_data, 1 /* COHACC Override */, 4);
build_append_int_noprefix(table_data, 0, 4); /* Reserved */
@@ -404,15 +437,19 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
build_append_int_noprefix(table_data, 0, 3); /* Reserved */
/* Output Reference */
- if (vms->iommu == VIRT_IOMMU_SMMUV3) {
+ if (num_smmus) {
AcpiIortIdMapping *range;
/* translated RIDs connect to SMMUv3 node: RC -> SMMUv3 -> ITS */
- for (i = 0; i < smmu_idmaps->len; i++) {
- range = &g_array_index(smmu_idmaps, AcpiIortIdMapping, i);
- /* output IORT node is the smmuv3 node */
- build_iort_id_mapping(table_data, range->input_base,
- range->id_count, smmu_offset);
+ for (i = 0; i < num_smmus; i++) {
+ sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
+
+ for (j = 0; j < sdev->idmaps->len; j++) {
+ range = &g_array_index(sdev->idmaps, AcpiIortIdMapping, j);
+ /* output IORT node is the smmuv3 node */
+ build_iort_id_mapping(table_data, range->input_base,
+ range->id_count, sdev->offset);
+ }
}
/* bypassed RIDs connect to ITS group node directly: RC -> ITS */
@@ -428,8 +465,12 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
}
acpi_table_end(linker, &table);
- g_array_free(smmu_idmaps, true);
g_array_free(its_idmaps, true);
+ for (i = 0; i < num_smmus; i++) {
+ sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
+ g_array_free(sdev->idmaps, true);
+ }
+ g_array_free(smmuv3_devs, true);
}
/*
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9a6cd085a3..73bd2bd5f2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1614,6 +1614,7 @@ static void create_pcie(VirtMachineState *vms)
create_smmu(vms, vms->bus);
qemu_fdt_setprop_cells(ms->fdt, nodename, "iommu-map",
0x0, vms->iommu_phandle, 0x0, 0x10000);
+ vms->legacy_smmuv3_present = true;
break;
default:
g_assert_not_reached();
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index 9a1b0f53d2..8b1404b5f6 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -174,6 +174,7 @@ struct VirtMachineState {
char *oem_id;
char *oem_table_id;
bool ns_el2_virt_timer_irq;
+ bool legacy_smmuv3_present;
};
#define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build
2025-06-23 9:42 ` [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build Shameer Kolothum via
@ 2025-06-27 11:54 ` Eric Auger
0 siblings, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-06-27 11:54 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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 common code paths when we add that support.
>
> Tested-by: Nathan Chen <nathanc@nvidia.com>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
> ---
> hw/arm/virt-acpi-build.c | 109 +++++++++++++++++++++++++++------------
> hw/arm/virt.c | 1 +
> include/hw/arm/virt.h | 1 +
> 3 files changed, 77 insertions(+), 34 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 7e8e0f0298..28489cf59f 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -266,6 +266,34 @@ static int iort_idmap_compare(gconstpointer a, gconstpointer b)
> return idmap_a->input_base - idmap_b->input_base;
> }
>
> +typedef struct AcpiIortSMMUv3Dev {
> + int irq;
> + hwaddr base;
> + GArray *idmaps;
> + /* Offset of the SMMUv3 IORT Node relative to the start of the IORT */
> + size_t offset;
> +} AcpiIortSMMUv3Dev;
> +
> +static void populate_smmuv3_legacy_dev(GArray *sdev_blob)
> +{
> + VirtMachineState *vms = VIRT_MACHINE(qdev_get_machine());
> + AcpiIortSMMUv3Dev sdev;
> +
> + sdev.idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
> + object_child_foreach_recursive(object_get_root(), iort_host_bridges,
> + sdev.idmaps);
> + /*
> + * There can be only one legacy SMMUv3("iommu=smmuv3") as it is a machine
> + * wide one. Since it may cover multiple PCIe RCs(based on "bypass_iommu"
> + * property), may have multiple SMMUv3 idmaps. Sort it by input_base.
> + */
> + g_array_sort(sdev.idmaps, iort_idmap_compare);
> +
> + sdev.base = vms->memmap[VIRT_SMMU].base;
> + sdev.irq = vms->irqmap[VIRT_SMMU] + ARM_SPI_BASE;
> + g_array_append_val(sdev_blob, sdev);
> +}
> +
> /*
> * Input Output Remapping Table (IORT)
> * Conforms to "IO Remapping Table System Software on ARM Platforms",
> @@ -274,11 +302,12 @@ static int iort_idmap_compare(gconstpointer a, gconstpointer b)
> static void
> build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> {
> - int i, nb_nodes, rc_mapping_count;
> - size_t node_size, smmu_offset = 0;
> - AcpiIortIdMapping *idmap;
> + int i, j, nb_nodes, rc_mapping_count;
> + AcpiIortSMMUv3Dev *sdev;
> + size_t node_size;
> + int num_smmus = 0;
> uint32_t id = 0;
> - GArray *smmu_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
> + GArray *smmuv3_devs = g_array_new(false, true, sizeof(AcpiIortSMMUv3Dev));
> GArray *its_idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
>
> AcpiTable table = { .sig = "IORT", .rev = 3, .oem_id = vms->oem_id,
> @@ -286,28 +315,32 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> /* Table 2 The IORT */
> acpi_table_begin(&table, table_data);
>
> - if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> - AcpiIortIdMapping next_range = {0};
> -
> - object_child_foreach_recursive(object_get_root(),
> - iort_host_bridges, smmu_idmaps);
> -
> - /* Sort the smmu idmap by input_base */
> - g_array_sort(smmu_idmaps, iort_idmap_compare);
> + nb_nodes = 2; /* RC, ITS */
> + if (vms->legacy_smmuv3_present) {
> + populate_smmuv3_legacy_dev(smmuv3_devs);
> + }
>
> + num_smmus = smmuv3_devs->len;
> + if (num_smmus) {
> + AcpiIortIdMapping next_range = {0};
> + int smmu_map_cnt = 0;
> /*
> * Split the whole RIDs by mapping from RC to SMMU,
> * build the ID mapping from RC to ITS directly.
> */
> - for (i = 0; i < smmu_idmaps->len; i++) {
> - idmap = &g_array_index(smmu_idmaps, AcpiIortIdMapping, i);
> -
> - if (next_range.input_base < idmap->input_base) {
> - next_range.id_count = idmap->input_base - next_range.input_base;
> - g_array_append_val(its_idmaps, next_range);
> + for (i = 0; i < num_smmus; i++) {
> + sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
> + for (j = 0; j < sdev->idmaps->len; j++) {
> + AcpiIortIdMapping *idmap = &g_array_index(sdev->idmaps,
> + AcpiIortIdMapping, j);
> + if (next_range.input_base < idmap->input_base) {
> + next_range.id_count = idmap->input_base -
> + next_range.input_base;
> + g_array_append_val(its_idmaps, next_range);
> + }
> + next_range.input_base = idmap->input_base + idmap->id_count;
> + smmu_map_cnt++;
> }
> -
> - next_range.input_base = idmap->input_base + idmap->id_count;
> }
>
> /* Append the last RC -> ITS ID mapping */
> @@ -316,10 +349,9 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> g_array_append_val(its_idmaps, next_range);
> }
>
> - nb_nodes = 3; /* RC, ITS, SMMUv3 */
> - rc_mapping_count = smmu_idmaps->len + its_idmaps->len;
> + nb_nodes += num_smmus;
> + rc_mapping_count = smmu_map_cnt + its_idmaps->len;
> } else {
> - nb_nodes = 2; /* RC, ITS */
> rc_mapping_count = 1;
> }
> /* Number of IORT Nodes */
> @@ -341,10 +373,11 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> /* GIC ITS Identifier Array */
> build_append_int_noprefix(table_data, 0 /* MADT translation_id */, 4);
>
> - if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> - int irq = vms->irqmap[VIRT_SMMU] + ARM_SPI_BASE;
> + for (i = 0; i < num_smmus; i++) {
> + sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
> + int irq = sdev->irq;
>
> - smmu_offset = table_data->len - table.table_offset;
> + sdev->offset = table_data->len - table.table_offset;
> /* Table 9 SMMUv3 Format */
> build_append_int_noprefix(table_data, 4 /* SMMUv3 */, 1); /* Type */
> node_size = SMMU_V3_ENTRY_SIZE + ID_MAPPING_ENTRY_SIZE;
> @@ -355,7 +388,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> /* Reference to ID Array */
> build_append_int_noprefix(table_data, SMMU_V3_ENTRY_SIZE, 4);
> /* Base address */
> - build_append_int_noprefix(table_data, vms->memmap[VIRT_SMMU].base, 8);
> + build_append_int_noprefix(table_data, sdev->base, 8);
> /* Flags */
> build_append_int_noprefix(table_data, 1 /* COHACC Override */, 4);
> build_append_int_noprefix(table_data, 0, 4); /* Reserved */
> @@ -404,15 +437,19 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> build_append_int_noprefix(table_data, 0, 3); /* Reserved */
>
> /* Output Reference */
> - if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> + if (num_smmus) {
> AcpiIortIdMapping *range;
>
> /* translated RIDs connect to SMMUv3 node: RC -> SMMUv3 -> ITS */
> - for (i = 0; i < smmu_idmaps->len; i++) {
> - range = &g_array_index(smmu_idmaps, AcpiIortIdMapping, i);
> - /* output IORT node is the smmuv3 node */
> - build_iort_id_mapping(table_data, range->input_base,
> - range->id_count, smmu_offset);
> + for (i = 0; i < num_smmus; i++) {
> + sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
> +
> + for (j = 0; j < sdev->idmaps->len; j++) {
> + range = &g_array_index(sdev->idmaps, AcpiIortIdMapping, j);
> + /* output IORT node is the smmuv3 node */
> + build_iort_id_mapping(table_data, range->input_base,
> + range->id_count, sdev->offset);
> + }
> }
>
> /* bypassed RIDs connect to ITS group node directly: RC -> ITS */
> @@ -428,8 +465,12 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> }
>
> acpi_table_end(linker, &table);
> - g_array_free(smmu_idmaps, true);
> g_array_free(its_idmaps, true);
> + for (i = 0; i < num_smmus; i++) {
> + sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
> + g_array_free(sdev->idmaps, true);
> + }
> + g_array_free(smmuv3_devs, true);
> }
>
> /*
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 9a6cd085a3..73bd2bd5f2 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1614,6 +1614,7 @@ static void create_pcie(VirtMachineState *vms)
> create_smmu(vms, vms->bus);
> qemu_fdt_setprop_cells(ms->fdt, nodename, "iommu-map",
> 0x0, vms->iommu_phandle, 0x0, 0x10000);
> + vms->legacy_smmuv3_present = true;
> break;
> default:
> g_assert_not_reached();
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 9a1b0f53d2..8b1404b5f6 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -174,6 +174,7 @@ struct VirtMachineState {
> char *oem_id;
> char *oem_table_id;
> bool ns_el2_virt_timer_irq;
> + bool legacy_smmuv3_present;
> };
>
> #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 03/11] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
2025-06-23 9:42 ` [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
2025-06-23 9:42 ` [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 9:42 ` [PATCH v5 04/11] hw/arm/virt: Factor out common SMMUV3 dt bindings code Shameer Kolothum via
` (9 subsequent siblings)
12 siblings, 0 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 a SMMUv3 will
be something like below,
-device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0
-device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1
...
+--------------------+ +--------------------+
| Root Complex 0 | | Root Complex 1 |
| | | |
| Requestor IDs | | Requestor IDs |
| 0x0000 - 0x00FF | | 0x0100 - 0x01FF |
+---------+----------+ +---------+----------+
| |
| |
| Stream ID Mapping |
v v
+--------------------+ +--------------------+
| SMMUv3 Node 0 | | SMMUv3 Node 1 |
| | | |
| Stream IDs 0x0000- | | Stream IDs 0x0100- |
| 0x00FF mapped from | | 0x01FF mapped from |
| RC0 Requestor IDs | | RC1 Requestor IDs |
+--------------------+ +--------------------+
| |
| |
+----------------+---------------+
|
|Device ID Mapping
v
+----------------------------+
| ITS Node 0 |
| |
| Device IDs: |
| 0x0000 - 0x00FF (from RC0) |
| 0x0100 - 0x01FF (from RC1) |
| 0x0200 - 0xFFFF (No SMMU) |
+----------------------------+
Tested-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/virt-acpi-build.c | 55 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 28489cf59f..bde44624cf 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -43,6 +43,7 @@
#include "hw/acpi/generic_event_device.h"
#include "hw/acpi/tpm.h"
#include "hw/acpi/hmat.h"
+#include "hw/arm/smmuv3.h"
#include "hw/pci/pcie_host.h"
#include "hw/pci/pci.h"
#include "hw/pci/pci_bus.h"
@@ -294,6 +295,58 @@ static void populate_smmuv3_legacy_dev(GArray *sdev_blob)
g_array_append_val(sdev_blob, sdev);
}
+static int smmuv3_dev_idmap_compare(gconstpointer a, gconstpointer b)
+{
+ AcpiIortSMMUv3Dev *sdev_a = (AcpiIortSMMUv3Dev *)a;
+ AcpiIortSMMUv3Dev *sdev_b = (AcpiIortSMMUv3Dev *)b;
+ AcpiIortIdMapping *map_a = &g_array_index(sdev_a->idmaps,
+ AcpiIortIdMapping, 0);
+ AcpiIortIdMapping *map_b = &g_array_index(sdev_b->idmaps,
+ AcpiIortIdMapping, 0);
+ return map_a->input_base - map_b->input_base;
+}
+
+static int iort_smmuv3_devices(Object *obj, void *opaque)
+{
+ VirtMachineState *vms = VIRT_MACHINE(qdev_get_machine());
+ GArray *sdev_blob = opaque;
+ AcpiIortIdMapping idmap;
+ PlatformBusDevice *pbus;
+ AcpiIortSMMUv3Dev sdev;
+ int min_bus, max_bus;
+ SysBusDevice *sbdev;
+ PCIBus *bus;
+
+ if (!object_dynamic_cast(obj, TYPE_ARM_SMMUV3)) {
+ return 0;
+ }
+
+ bus = PCI_BUS(object_property_get_link(obj, "primary-bus", &error_abort));
+ pbus = PLATFORM_BUS_DEVICE(vms->platform_bus_dev);
+ sbdev = SYS_BUS_DEVICE(obj);
+ sdev.base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
+ sdev.base += vms->memmap[VIRT_PLATFORM_BUS].base;
+ sdev.irq = platform_bus_get_irqn(pbus, sbdev, 0);
+ sdev.irq += vms->irqmap[VIRT_PLATFORM_BUS];
+ sdev.irq += ARM_SPI_BASE;
+
+ pci_bus_range(bus, &min_bus, &max_bus);
+ sdev.idmaps = g_array_new(false, true, sizeof(AcpiIortIdMapping));
+ idmap.input_base = min_bus << 8,
+ idmap.id_count = (max_bus - min_bus + 1) << 8,
+ g_array_append_val(sdev.idmaps, idmap);
+ g_array_append_val(sdev_blob, sdev);
+ return 0;
+}
+
+static void populate_smmuv3_dev(GArray *sdev_blob)
+{
+ object_child_foreach_recursive(object_get_root(),
+ iort_smmuv3_devices, sdev_blob);
+ /* Sort the smmuv3 devices(if any) by smmu idmap input_base */
+ g_array_sort(sdev_blob, smmuv3_dev_idmap_compare);
+}
+
/*
* Input Output Remapping Table (IORT)
* Conforms to "IO Remapping Table System Software on ARM Platforms",
@@ -318,6 +371,8 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
nb_nodes = 2; /* RC, ITS */
if (vms->legacy_smmuv3_present) {
populate_smmuv3_legacy_dev(smmuv3_devs);
+ } else {
+ populate_smmuv3_dev(smmuv3_devs);
}
num_smmus = smmuv3_devs->len;
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* [PATCH v5 04/11] hw/arm/virt: Factor out common SMMUV3 dt bindings code
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (2 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 03/11] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 9:42 ` [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
` (8 subsequent siblings)
12 siblings, 0 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
No functional changes intended. This will be useful when we
add support for user-creatable smmuv3 device.
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/virt.c | 54 +++++++++++++++++++++++++++------------------------
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 73bd2bd5f2..71b923f786 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1412,19 +1412,43 @@ static void create_pcie_irq_map(const MachineState *ms,
0x7 /* PCI irq */);
}
+static void create_smmuv3_dt_bindings(const VirtMachineState *vms, hwaddr base,
+ hwaddr size, int irq)
+{
+ char *node;
+ const char compat[] = "arm,smmu-v3";
+ const char irq_names[] = "eventq\0priq\0cmdq-sync\0gerror";
+ MachineState *ms = MACHINE(vms);
+
+ node = g_strdup_printf("/smmuv3@%" PRIx64, base);
+ qemu_fdt_add_subnode(ms->fdt, node);
+ qemu_fdt_setprop(ms->fdt, node, "compatible", compat, sizeof(compat));
+ qemu_fdt_setprop_sized_cells(ms->fdt, node, "reg", 2, base, 2, size);
+
+ qemu_fdt_setprop_cells(ms->fdt, node, "interrupts",
+ GIC_FDT_IRQ_TYPE_SPI, irq , GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
+ GIC_FDT_IRQ_TYPE_SPI, irq + 1, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
+ GIC_FDT_IRQ_TYPE_SPI, irq + 2, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
+ GIC_FDT_IRQ_TYPE_SPI, irq + 3, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI);
+
+ qemu_fdt_setprop(ms->fdt, node, "interrupt-names", irq_names,
+ sizeof(irq_names));
+
+ qemu_fdt_setprop(ms->fdt, node, "dma-coherent", NULL, 0);
+ qemu_fdt_setprop_cell(ms->fdt, node, "#iommu-cells", 1);
+ qemu_fdt_setprop_cell(ms->fdt, node, "phandle", vms->iommu_phandle);
+ g_free(node);
+}
+
static void create_smmu(const VirtMachineState *vms,
PCIBus *bus)
{
VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(vms);
- char *node;
- const char compat[] = "arm,smmu-v3";
int irq = vms->irqmap[VIRT_SMMU];
int i;
hwaddr base = vms->memmap[VIRT_SMMU].base;
hwaddr size = vms->memmap[VIRT_SMMU].size;
- const char irq_names[] = "eventq\0priq\0cmdq-sync\0gerror";
DeviceState *dev;
- MachineState *ms = MACHINE(vms);
if (vms->iommu != VIRT_IOMMU_SMMUV3 || !vms->iommu_phandle) {
return;
@@ -1443,27 +1467,7 @@ static void create_smmu(const VirtMachineState *vms,
sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
qdev_get_gpio_in(vms->gic, irq + i));
}
-
- node = g_strdup_printf("/smmuv3@%" PRIx64, base);
- qemu_fdt_add_subnode(ms->fdt, node);
- qemu_fdt_setprop(ms->fdt, node, "compatible", compat, sizeof(compat));
- qemu_fdt_setprop_sized_cells(ms->fdt, node, "reg", 2, base, 2, size);
-
- qemu_fdt_setprop_cells(ms->fdt, node, "interrupts",
- GIC_FDT_IRQ_TYPE_SPI, irq , GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
- GIC_FDT_IRQ_TYPE_SPI, irq + 1, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
- GIC_FDT_IRQ_TYPE_SPI, irq + 2, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI,
- GIC_FDT_IRQ_TYPE_SPI, irq + 3, GIC_FDT_IRQ_FLAGS_EDGE_LO_HI);
-
- qemu_fdt_setprop(ms->fdt, node, "interrupt-names", irq_names,
- sizeof(irq_names));
-
- qemu_fdt_setprop(ms->fdt, node, "dma-coherent", NULL, 0);
-
- qemu_fdt_setprop_cell(ms->fdt, node, "#iommu-cells", 1);
-
- qemu_fdt_setprop_cell(ms->fdt, node, "phandle", vms->iommu_phandle);
- g_free(node);
+ create_smmuv3_dt_bindings(vms, base, size, irq);
}
static void create_virtio_iommu_dt_bindings(VirtMachineState *vms)
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (3 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 04/11] hw/arm/virt: Factor out common SMMUV3 dt bindings code Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:35 ` Jonathan Cameron via
2025-06-23 9:42 ` [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
` (7 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
From: Nicolin Chen <nicolinc@nvidia.com>
This is useful as the subsequent support for new SMMUv3 dev will also
use the same.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Donald Dutile <ddutile@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Nathan Chen <nathanc@nvidia.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/virt.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 71b923f786..ae30320c38 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -146,6 +146,9 @@ static void arm_virt_compat_set(MachineClass *mc)
#define LEGACY_RAMLIMIT_GB 255
#define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB)
+/* MMIO region size for SMMUv3 */
+#define SMMU_IO_LEN 0x20000
+
/* Addresses and sizes of our components.
* 0..128MB is space for a flash device so we can run bootrom code such as UEFI.
* 128MB..256MB is used for miscellaneous device I/O.
@@ -177,7 +180,7 @@ static const MemMapEntry base_memmap[] = {
[VIRT_FW_CFG] = { 0x09020000, 0x00000018 },
[VIRT_GPIO] = { 0x09030000, 0x00001000 },
[VIRT_UART1] = { 0x09040000, 0x00001000 },
- [VIRT_SMMU] = { 0x09050000, 0x00020000 },
+ [VIRT_SMMU] = { 0x09050000, SMMU_IO_LEN },
[VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN },
[VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN },
[VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN},
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro
2025-06-23 9:42 ` [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
@ 2025-06-23 11:35 ` Jonathan Cameron via
0 siblings, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:35 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:24 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> From: Nicolin Chen <nicolinc@nvidia.com>
>
> This is useful as the subsequent support for new SMMUv3 dev will also
> use the same.
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Donald Dutile <ddutile@redhat.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Nathan Chen <nathanc@nvidia.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> hw/arm/virt.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 71b923f786..ae30320c38 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -146,6 +146,9 @@ static void arm_virt_compat_set(MachineClass *mc)
> #define LEGACY_RAMLIMIT_GB 255
> #define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB)
>
> +/* MMIO region size for SMMUv3 */
> +#define SMMU_IO_LEN 0x20000
> +
> /* Addresses and sizes of our components.
> * 0..128MB is space for a flash device so we can run bootrom code such as UEFI.
> * 128MB..256MB is used for miscellaneous device I/O.
> @@ -177,7 +180,7 @@ static const MemMapEntry base_memmap[] = {
> [VIRT_FW_CFG] = { 0x09020000, 0x00000018 },
> [VIRT_GPIO] = { 0x09030000, 0x00001000 },
> [VIRT_UART1] = { 0x09040000, 0x00001000 },
> - [VIRT_SMMU] = { 0x09050000, 0x00020000 },
> + [VIRT_SMMU] = { 0x09050000, SMMU_IO_LEN },
> [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN },
> [VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN },
> [VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN},
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (4 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:39 ` Jonathan Cameron via
2025-06-27 12:04 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
` (6 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 ops.
This behavior works for now because QEMU's IOMMU implementations are
globally scoped, and host bridges rely on the bypass_iommu property
to skip IOMMU translation when needed.
However, this model will break with the soon to be introduced
arm-smmuv3 device, which allows users to associate the IOMMU
with a specific PCIe root complex (e.g., the default pcie.0
or a pxb-pcie root complex).
For example, consider the following setup with multiple root
complexes:
-device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
...
-device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
-device pcie-root-port,id=pcie.port1,bus=pcie.1 \
-device virtio-net-pci,bus=pcie.port1
In Qemu, pxb-pcie acts as a special root complex whose parent is
effectively the default root complex(pcie.0). Hence, though pcie.1
has no associated SMMUv3 as per above, pci_device_get_iommu_bus_devfn()
will incorrectly return the IOMMU ops from pcie.0 due to the fallback
via parent_dev.
To fix this, introduce a new helper pci_setup_iommu_per_bus() that
explicitly sets the new iommu_per_bus field in the PCIBus structure.
Update pci_device_get_iommu_bus_devfn() to use this when determining
the correct IOMMU ops, ensuring accurate behavior for per-bus IOMMUs.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
Please refer cover letter for more details on the issue that
this is trying to fix.
---
hw/pci/pci.c | 25 +++++++++++++++++++++++++
include/hw/pci/pci.h | 2 ++
include/hw/pci/pci_bus.h | 1 +
3 files changed, 28 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index c70b5ceeba..e1940c05d9 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2909,6 +2909,19 @@ static void pci_device_get_iommu_bus_devfn(PCIDevice *dev,
}
}
+ /*
+ * When multiple PCI Express Root Buses are defined using pxb-pcie,
+ * the IOMMU configuration may be specific to each root bus. However,
+ * pxb-pcie acts as a special root complex whose parent is effectively
+ * the default root complex(pcie.0). Ensure that we retrieve the
+ * correct IOMMU ops(if any) in such cases.
+ */
+ if (pci_bus_is_express(iommu_bus) && pci_bus_is_root(iommu_bus)) {
+ if (!iommu_bus->iommu_per_bus && parent_bus->iommu_per_bus) {
+ break;
+ }
+ }
+
iommu_bus = parent_bus;
}
@@ -3169,6 +3182,18 @@ void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
bus->iommu_opaque = opaque;
}
+/*
+ * This is same as pci_setup_iommu() except it sets the iommu_per_bus
+ * to true indicating the iommu is specific to this bus and
+ * not applicable to any parent or child.
+ */
+void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
+ void *opaque)
+{
+ pci_setup_iommu(bus, ops, opaque);
+ bus->iommu_per_bus = true;
+}
+
static void pci_dev_get_w64(PCIBus *b, PCIDevice *dev, void *opaque)
{
Range *range = opaque;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index df3cc7b875..a3e0870a15 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -764,6 +764,8 @@ int pci_iommu_unregister_iotlb_notifier(PCIDevice *dev, uint32_t pasid,
*/
void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque);
+void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque);
+
pcibus_t pci_bar_address(PCIDevice *d,
int reg, uint8_t type, pcibus_t size);
diff --git a/include/hw/pci/pci_bus.h b/include/hw/pci/pci_bus.h
index 2261312546..c738446788 100644
--- a/include/hw/pci/pci_bus.h
+++ b/include/hw/pci/pci_bus.h
@@ -35,6 +35,7 @@ struct PCIBus {
enum PCIBusFlags flags;
const PCIIOMMUOps *iommu_ops;
void *iommu_opaque;
+ bool iommu_per_bus;
uint8_t devfn_min;
uint32_t slot_reserved_mask;
pci_set_irq_fn set_irq;
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
2025-06-23 9:42 ` [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
@ 2025-06-23 11:39 ` Jonathan Cameron via
2025-06-27 12:04 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:39 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:25 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 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 ops.
>
> This behavior works for now because QEMU's IOMMU implementations are
> globally scoped, and host bridges rely on the bypass_iommu property
> to skip IOMMU translation when needed.
>
> However, this model will break with the soon to be introduced
> arm-smmuv3 device, which allows users to associate the IOMMU
> with a specific PCIe root complex (e.g., the default pcie.0
> or a pxb-pcie root complex).
>
> For example, consider the following setup with multiple root
> complexes:
>
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
> ...
> -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> -device pcie-root-port,id=pcie.port1,bus=pcie.1 \
> -device virtio-net-pci,bus=pcie.port1
>
> In Qemu, pxb-pcie acts as a special root complex whose parent is
> effectively the default root complex(pcie.0). Hence, though pcie.1
> has no associated SMMUv3 as per above, pci_device_get_iommu_bus_devfn()
> will incorrectly return the IOMMU ops from pcie.0 due to the fallback
> via parent_dev.
>
> To fix this, introduce a new helper pci_setup_iommu_per_bus() that
> explicitly sets the new iommu_per_bus field in the PCIBus structure.
Maybe call out where this will later be called from?
Otherwise seems like a reasonable solution to me.
One trivial comment inline.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Update pci_device_get_iommu_bus_devfn() to use this when determining
> the correct IOMMU ops, ensuring accurate behavior for per-bus IOMMUs.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> Please refer cover letter for more details on the issue that
> this is trying to fix.
> ---
> hw/pci/pci.c | 25 +++++++++++++++++++++++++
> include/hw/pci/pci.h | 2 ++
> include/hw/pci/pci_bus.h | 1 +
> 3 files changed, 28 insertions(+)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index c70b5ceeba..e1940c05d9 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -3169,6 +3182,18 @@ void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
> bus->iommu_opaque = opaque;
> }
>
> +/*
> + * This is same as pci_setup_iommu() except it sets the iommu_per_bus
> + * to true indicating the iommu is specific to this bus and
Trivial: Odd line wrap. At least not can go up a line.
> + * not applicable to any parent or child.
> + */
> +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
> + void *opaque)
> +{
> + pci_setup_iommu(bus, ops, opaque);
> + bus->iommu_per_bus = true;
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
2025-06-23 9:42 ` [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
2025-06-23 11:39 ` Jonathan Cameron via
@ 2025-06-27 12:04 ` Eric Auger
2025-06-30 7:05 ` Shameerali Kolothum Thodi via
1 sibling, 1 reply; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:04 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
Hi Shameer,
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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 ops.
>
> This behavior works for now because QEMU's IOMMU implementations are
> globally scoped, and host bridges rely on the bypass_iommu property
> to skip IOMMU translation when needed.
>
> However, this model will break with the soon to be introduced
> arm-smmuv3 device, which allows users to associate the IOMMU
> with a specific PCIe root complex (e.g., the default pcie.0
> or a pxb-pcie root complex).
>
> For example, consider the following setup with multiple root
> complexes:
>
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
> ...
> -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> -device pcie-root-port,id=pcie.port1,bus=pcie.1 \
> -device virtio-net-pci,bus=pcie.port1
>
> In Qemu, pxb-pcie acts as a special root complex whose parent is
> effectively the default root complex(pcie.0). Hence, though pcie.1
> has no associated SMMUv3 as per above, pci_device_get_iommu_bus_devfn()
> will incorrectly return the IOMMU ops from pcie.0 due to the fallback
> via parent_dev.
>
> To fix this, introduce a new helper pci_setup_iommu_per_bus() that
> explicitly sets the new iommu_per_bus field in the PCIBus structure.
> Update pci_device_get_iommu_bus_devfn() to use this when determining
> the correct IOMMU ops, ensuring accurate behavior for per-bus IOMMUs.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> Please refer cover letter for more details on the issue that
> this is trying to fix.
> ---
> hw/pci/pci.c | 25 +++++++++++++++++++++++++
> include/hw/pci/pci.h | 2 ++
> include/hw/pci/pci_bus.h | 1 +
> 3 files changed, 28 insertions(+)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index c70b5ceeba..e1940c05d9 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2909,6 +2909,19 @@ static void pci_device_get_iommu_bus_devfn(PCIDevice *dev,
> }
> }
>
> + /*
> + * When multiple PCI Express Root Buses are defined using pxb-pcie,
> + * the IOMMU configuration may be specific to each root bus. However,
> + * pxb-pcie acts as a special root complex whose parent is effectively
> + * the default root complex(pcie.0). Ensure that we retrieve the
I generally leave a space before the opening bracket. Here and elsewhere
> + * correct IOMMU ops(if any) in such cases.
> + */
> + if (pci_bus_is_express(iommu_bus) && pci_bus_is_root(iommu_bus)) {
> + if (!iommu_bus->iommu_per_bus && parent_bus->iommu_per_bus) {
> + break;
> + }
> + }
> +
> iommu_bus = parent_bus;
> }
>
> @@ -3169,6 +3182,18 @@ void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
> bus->iommu_opaque = opaque;
> }
>
> +/*
> + * This is same as pci_setup_iommu() except it sets the iommu_per_bus
> + * to true indicating the iommu is specific to this bus and
> + * not applicable to any parent or child.
or child? if there are root ports below, doesn't it protect them as well?
Besides looks OK to me. However I would encourage you to add pci
maintainers (MST) in to.
besides,
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
> + */
> +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
> + void *opaque)
> +{
> + pci_setup_iommu(bus, ops, opaque);
> + bus->iommu_per_bus = true;
> +}
> +
> static void pci_dev_get_w64(PCIBus *b, PCIDevice *dev, void *opaque)
> {
> Range *range = opaque;
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index df3cc7b875..a3e0870a15 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -764,6 +764,8 @@ int pci_iommu_unregister_iotlb_notifier(PCIDevice *dev, uint32_t pasid,
> */
> void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque);
>
> +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque);
> +
> pcibus_t pci_bar_address(PCIDevice *d,
> int reg, uint8_t type, pcibus_t size);
>
> diff --git a/include/hw/pci/pci_bus.h b/include/hw/pci/pci_bus.h
> index 2261312546..c738446788 100644
> --- a/include/hw/pci/pci_bus.h
> +++ b/include/hw/pci/pci_bus.h
> @@ -35,6 +35,7 @@ struct PCIBus {
> enum PCIBusFlags flags;
> const PCIIOMMUOps *iommu_ops;
> void *iommu_opaque;
> + bool iommu_per_bus;
> uint8_t devfn_min;
> uint32_t slot_reserved_mask;
> pci_set_irq_fn set_irq;
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
2025-06-27 12:04 ` Eric Auger
@ 2025-06-30 7:05 ` Shameerali Kolothum Thodi via
0 siblings, 0 replies; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-06-30 7:05 UTC (permalink / raw)
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, June 27, 2025 1:04 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 06/11] hw/pci: Introduce
> pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
>
> Hi Shameer,
>
> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> > 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 ops.
> >
> > This behavior works for now because QEMU's IOMMU implementations
> are
> > globally scoped, and host bridges rely on the bypass_iommu property
> > to skip IOMMU translation when needed.
> >
> > However, this model will break with the soon to be introduced
> > arm-smmuv3 device, which allows users to associate the IOMMU
> > with a specific PCIe root complex (e.g., the default pcie.0
> > or a pxb-pcie root complex).
> >
> > For example, consider the following setup with multiple root
> > complexes:
> >
> > -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
> > ...
> > -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> > -device pcie-root-port,id=pcie.port1,bus=pcie.1 \
> > -device virtio-net-pci,bus=pcie.port1
> >
> > In Qemu, pxb-pcie acts as a special root complex whose parent is
> > effectively the default root complex(pcie.0). Hence, though pcie.1
> > has no associated SMMUv3 as per above,
> pci_device_get_iommu_bus_devfn()
> > will incorrectly return the IOMMU ops from pcie.0 due to the fallback
> > via parent_dev.
> >
> > To fix this, introduce a new helper pci_setup_iommu_per_bus() that
> > explicitly sets the new iommu_per_bus field in the PCIBus structure.
> > Update pci_device_get_iommu_bus_devfn() to use this when determining
> > the correct IOMMU ops, ensuring accurate behavior for per-bus IOMMUs.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> > Please refer cover letter for more details on the issue that
> > this is trying to fix.
> > ---
> > hw/pci/pci.c | 25 +++++++++++++++++++++++++
> > include/hw/pci/pci.h | 2 ++
> > include/hw/pci/pci_bus.h | 1 +
> > 3 files changed, 28 insertions(+)
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index c70b5ceeba..e1940c05d9 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -2909,6 +2909,19 @@ static void
> pci_device_get_iommu_bus_devfn(PCIDevice *dev,
> > }
> > }
> >
> > + /*
> > + * When multiple PCI Express Root Buses are defined using pxb-
> pcie,
> > + * the IOMMU configuration may be specific to each root bus.
> However,
> > + * pxb-pcie acts as a special root complex whose parent is
> effectively
> > + * the default root complex(pcie.0). Ensure that we retrieve the
> I generally leave a space before the opening bracket. Here and elsewhere
Ok.
> > + * correct IOMMU ops(if any) in such cases.
> > + */
> > + if (pci_bus_is_express(iommu_bus) &&
> pci_bus_is_root(iommu_bus)) {
> > + if (!iommu_bus->iommu_per_bus && parent_bus-
> >iommu_per_bus) {
> > + break;
> > + }
> > + }
> > +
> > iommu_bus = parent_bus;
> > }
> >
> > @@ -3169,6 +3182,18 @@ void pci_setup_iommu(PCIBus *bus, const
> PCIIOMMUOps *ops, void *opaque)
> > bus->iommu_opaque = opaque;
> > }
> >
> > +/*
> > + * This is same as pci_setup_iommu() except it sets the iommu_per_bus
> > + * to true indicating the iommu is specific to this bus and
> > + * not applicable to any parent or child.
> or child? if there are root ports below, doesn't it protect them as well?
Yeah. It will cover root ports. Actually I meant the root buses and specifically
the pci.0 and pxb-pcie special relationship here. I will update and make it clear.
>
> Besides looks OK to me. However I would encourage you to add pci
> maintainers (MST) in to.
Sure.
> besides,
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks,
Shameer
>
> Eric
> > + */
> > +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
> > + void *opaque)
> > +{
> > + pci_setup_iommu(bus, ops, opaque);
> > + bus->iommu_per_bus = true;
> > +}
> > +
> > static void pci_dev_get_w64(PCIBus *b, PCIDevice *dev, void *opaque)
> > {
> > Range *range = opaque;
> > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > index df3cc7b875..a3e0870a15 100644
> > --- a/include/hw/pci/pci.h
> > +++ b/include/hw/pci/pci.h
> > @@ -764,6 +764,8 @@ int pci_iommu_unregister_iotlb_notifier(PCIDevice
> *dev, uint32_t pasid,
> > */
> > void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void
> *opaque);
> >
> > +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
> void *opaque);
> > +
> > pcibus_t pci_bar_address(PCIDevice *d,
> > int reg, uint8_t type, pcibus_t size);
> >
> > diff --git a/include/hw/pci/pci_bus.h b/include/hw/pci/pci_bus.h
> > index 2261312546..c738446788 100644
> > --- a/include/hw/pci/pci_bus.h
> > +++ b/include/hw/pci/pci_bus.h
> > @@ -35,6 +35,7 @@ struct PCIBus {
> > enum PCIBusFlags flags;
> > const PCIIOMMUOps *iommu_ops;
> > void *iommu_opaque;
> > + bool iommu_per_bus;
> > uint8_t devfn_min;
> > uint32_t slot_reserved_mask;
> > pci_set_irq_fn set_irq;
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (5 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:46 ` Jonathan Cameron via
2025-06-27 12:05 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
` (5 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 limitations in QEMU’s device tree support, specifically
its inability to properly present pxb-pcie based root complexes and
their devices, the device tree support for the new SMMUv3 device is
limited to cases where it is attached to the default pcie.0 root complex.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/smmu-common.c | 8 +++++-
hw/arm/smmuv3.c | 2 ++
hw/arm/virt.c | 50 ++++++++++++++++++++++++++++++++++++
hw/core/sysbus-fdt.c | 3 +++
include/hw/arm/smmu-common.h | 1 +
5 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
index b15e7fd0e4..2ee4691299 100644
--- a/hw/arm/smmu-common.c
+++ b/hw/arm/smmu-common.c
@@ -959,7 +959,12 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
goto out_err;
}
}
- pci_setup_iommu(pci_bus, &smmu_ops, s);
+
+ if (s->smmu_per_bus) {
+ pci_setup_iommu_per_bus(pci_bus, &smmu_ops, s);
+ } else {
+ pci_setup_iommu(pci_bus, &smmu_ops, s);
+ }
return;
}
out_err:
@@ -984,6 +989,7 @@ static void smmu_base_reset_exit(Object *obj, ResetType type)
static const Property smmu_dev_properties[] = {
DEFINE_PROP_UINT8("bus_num", SMMUState, bus_num, 0),
+ DEFINE_PROP_BOOL("smmu_per_bus", SMMUState, smmu_per_bus, false),
DEFINE_PROP_LINK("primary-bus", SMMUState, primary_bus,
TYPE_PCI_BUS, PCIBus *),
};
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index ab67972353..bcf8af8dc7 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -1996,6 +1996,8 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
device_class_set_parent_realize(dc, smmu_realize,
&c->parent_realize);
device_class_set_props(dc, smmuv3_properties);
+ dc->hotpluggable = false;
+ dc->user_creatable = true;
}
static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ae30320c38..e52347634f 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -56,6 +56,7 @@
#include "qemu/cutils.h"
#include "qemu/error-report.h"
#include "qemu/module.h"
+#include "hw/pci/pci_bus.h"
#include "hw/pci-host/gpex.h"
#include "hw/virtio/virtio-pci.h"
#include "hw/core/sysbus-fdt.h"
@@ -1443,6 +1444,28 @@ static void create_smmuv3_dt_bindings(const VirtMachineState *vms, hwaddr base,
g_free(node);
}
+static void create_smmuv3_dev_dtb(VirtMachineState *vms,
+ DeviceState *dev, PCIBus *bus)
+{
+ PlatformBusDevice *pbus = PLATFORM_BUS_DEVICE(vms->platform_bus_dev);
+ SysBusDevice *sbdev = SYS_BUS_DEVICE(dev);
+ int irq = platform_bus_get_irqn(pbus, sbdev, 0);
+ hwaddr base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
+ MachineState *ms = MACHINE(vms);
+
+ if (strcmp("pcie.0", bus->qbus.name)) {
+ warn_report("SMMUv3 device only supported with pcie.0 for DT");
+ return;
+ }
+ base += vms->memmap[VIRT_PLATFORM_BUS].base;
+ irq += vms->irqmap[VIRT_PLATFORM_BUS];
+
+ vms->iommu_phandle = qemu_fdt_alloc_phandle(ms->fdt);
+ create_smmuv3_dt_bindings(vms, base, SMMU_IO_LEN, irq);
+ qemu_fdt_setprop_cells(ms->fdt, vms->pciehb_nodename, "iommu-map",
+ 0x0, vms->iommu_phandle, 0x0, 0x10000);
+}
+
static void create_smmu(const VirtMachineState *vms,
PCIBus *bus)
{
@@ -2932,6 +2955,16 @@ static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev,
qlist_append_str(reserved_regions, resv_prop_str);
qdev_prop_set_array(dev, "reserved-regions", reserved_regions);
g_free(resv_prop_str);
+ } else if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3)) {
+ if (vms->legacy_smmuv3_present || vms->iommu == VIRT_IOMMU_VIRTIO) {
+ error_setg(errp, "virt machine already has %s set. "
+ "Doesn't support incompatible iommus",
+ (vms->legacy_smmuv3_present) ?
+ "iommu=smmuv3" : "virtio-iommu");
+ } else if (vms->iommu == VIRT_IOMMU_NONE) {
+ /* The new SMMUv3 device is specific to the PCI bus */
+ object_property_set_bool(OBJECT(dev), "smmu_per_bus", true, NULL);
+ }
}
}
@@ -2955,6 +2988,22 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
virtio_md_pci_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
}
+ if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3)) {
+ if (!vms->legacy_smmuv3_present && vms->platform_bus_dev) {
+ PCIBus *bus;
+
+ bus = PCI_BUS(object_property_get_link(OBJECT(dev), "primary-bus",
+ &error_abort));
+ if (pci_bus_bypass_iommu(bus)) {
+ error_setg(errp, "Bypass option cannot be set for SMMUv3 "
+ "associated PCIe RC");
+ return;
+ }
+
+ create_smmuv3_dev_dtb(vms, dev, bus);
+ }
+ }
+
if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_IOMMU_PCI)) {
PCIDevice *pdev = PCI_DEVICE(dev);
@@ -3157,6 +3206,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_UEFI_VARS_SYSBUS);
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ARM_SMMUV3);
#ifdef CONFIG_TPM
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
#endif
diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
index c339a27875..e80776080b 100644
--- a/hw/core/sysbus-fdt.c
+++ b/hw/core/sysbus-fdt.c
@@ -31,6 +31,7 @@
#include "qemu/error-report.h"
#include "system/device_tree.h"
#include "system/tpm.h"
+#include "hw/arm/smmuv3.h"
#include "hw/platform-bus.h"
#include "hw/vfio/vfio-platform.h"
#include "hw/vfio/vfio-calxeda-xgmac.h"
@@ -518,6 +519,8 @@ static const BindingEntry bindings[] = {
#ifdef CONFIG_TPM
TYPE_BINDING(TYPE_TPM_TIS_SYSBUS, add_tpm_tis_fdt_node),
#endif
+ /* No generic DT support for smmuv3 dev. Support added for arm virt only */
+ TYPE_BINDING(TYPE_ARM_SMMUV3, no_fdt_node),
TYPE_BINDING(TYPE_RAMFB_DEVICE, no_fdt_node),
TYPE_BINDING(TYPE_UEFI_VARS_SYSBUS, add_uefi_vars_node),
TYPE_BINDING("", NULL), /* last element */
diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
index e5e2d09294..80d0fecfde 100644
--- a/include/hw/arm/smmu-common.h
+++ b/include/hw/arm/smmu-common.h
@@ -161,6 +161,7 @@ struct SMMUState {
QLIST_HEAD(, SMMUDevice) devices_with_notifiers;
uint8_t bus_num;
PCIBus *primary_bus;
+ bool smmu_per_bus; /* SMMU is specific to the primary_bus */
};
struct SMMUBaseClass {
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation
2025-06-23 9:42 ` [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
@ 2025-06-23 11:46 ` Jonathan Cameron via
2025-06-27 12:05 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:46 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:26 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 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 limitations in QEMU’s device tree support, specifically
> its inability to properly present pxb-pcie based root complexes and
> their devices, the device tree support for the new SMMUv3 device is
> limited to cases where it is attached to the default pcie.0 root complex.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation
2025-06-23 9:42 ` [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
2025-06-23 11:46 ` Jonathan Cameron via
@ 2025-06-27 12:05 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:05 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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 limitations in QEMU’s device tree support, specifically
> its inability to properly present pxb-pcie based root complexes and
> their devices, the device tree support for the new SMMUv3 device is
> limited to cases where it is attached to the default pcie.0 root complex.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
> ---
> hw/arm/smmu-common.c | 8 +++++-
> hw/arm/smmuv3.c | 2 ++
> hw/arm/virt.c | 50 ++++++++++++++++++++++++++++++++++++
> hw/core/sysbus-fdt.c | 3 +++
> include/hw/arm/smmu-common.h | 1 +
> 5 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
> index b15e7fd0e4..2ee4691299 100644
> --- a/hw/arm/smmu-common.c
> +++ b/hw/arm/smmu-common.c
> @@ -959,7 +959,12 @@ static void smmu_base_realize(DeviceState *dev, Error **errp)
> goto out_err;
> }
> }
> - pci_setup_iommu(pci_bus, &smmu_ops, s);
> +
> + if (s->smmu_per_bus) {
> + pci_setup_iommu_per_bus(pci_bus, &smmu_ops, s);
> + } else {
> + pci_setup_iommu(pci_bus, &smmu_ops, s);
> + }
> return;
> }
> out_err:
> @@ -984,6 +989,7 @@ static void smmu_base_reset_exit(Object *obj, ResetType type)
>
> static const Property smmu_dev_properties[] = {
> DEFINE_PROP_UINT8("bus_num", SMMUState, bus_num, 0),
> + DEFINE_PROP_BOOL("smmu_per_bus", SMMUState, smmu_per_bus, false),
> DEFINE_PROP_LINK("primary-bus", SMMUState, primary_bus,
> TYPE_PCI_BUS, PCIBus *),
> };
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index ab67972353..bcf8af8dc7 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -1996,6 +1996,8 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
> device_class_set_parent_realize(dc, smmu_realize,
> &c->parent_realize);
> device_class_set_props(dc, smmuv3_properties);
> + dc->hotpluggable = false;
> + dc->user_creatable = true;
> }
>
> static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ae30320c38..e52347634f 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -56,6 +56,7 @@
> #include "qemu/cutils.h"
> #include "qemu/error-report.h"
> #include "qemu/module.h"
> +#include "hw/pci/pci_bus.h"
> #include "hw/pci-host/gpex.h"
> #include "hw/virtio/virtio-pci.h"
> #include "hw/core/sysbus-fdt.h"
> @@ -1443,6 +1444,28 @@ static void create_smmuv3_dt_bindings(const VirtMachineState *vms, hwaddr base,
> g_free(node);
> }
>
> +static void create_smmuv3_dev_dtb(VirtMachineState *vms,
> + DeviceState *dev, PCIBus *bus)
> +{
> + PlatformBusDevice *pbus = PLATFORM_BUS_DEVICE(vms->platform_bus_dev);
> + SysBusDevice *sbdev = SYS_BUS_DEVICE(dev);
> + int irq = platform_bus_get_irqn(pbus, sbdev, 0);
> + hwaddr base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
> + MachineState *ms = MACHINE(vms);
> +
> + if (strcmp("pcie.0", bus->qbus.name)) {
> + warn_report("SMMUv3 device only supported with pcie.0 for DT");
> + return;
> + }
> + base += vms->memmap[VIRT_PLATFORM_BUS].base;
> + irq += vms->irqmap[VIRT_PLATFORM_BUS];
> +
> + vms->iommu_phandle = qemu_fdt_alloc_phandle(ms->fdt);
> + create_smmuv3_dt_bindings(vms, base, SMMU_IO_LEN, irq);
> + qemu_fdt_setprop_cells(ms->fdt, vms->pciehb_nodename, "iommu-map",
> + 0x0, vms->iommu_phandle, 0x0, 0x10000);
> +}
> +
> static void create_smmu(const VirtMachineState *vms,
> PCIBus *bus)
> {
> @@ -2932,6 +2955,16 @@ static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev,
> qlist_append_str(reserved_regions, resv_prop_str);
> qdev_prop_set_array(dev, "reserved-regions", reserved_regions);
> g_free(resv_prop_str);
> + } else if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3)) {
> + if (vms->legacy_smmuv3_present || vms->iommu == VIRT_IOMMU_VIRTIO) {
> + error_setg(errp, "virt machine already has %s set. "
> + "Doesn't support incompatible iommus",
> + (vms->legacy_smmuv3_present) ?
> + "iommu=smmuv3" : "virtio-iommu");
> + } else if (vms->iommu == VIRT_IOMMU_NONE) {
> + /* The new SMMUv3 device is specific to the PCI bus */
> + object_property_set_bool(OBJECT(dev), "smmu_per_bus", true, NULL);
> + }
> }
> }
>
> @@ -2955,6 +2988,22 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> virtio_md_pci_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
> }
>
> + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3)) {
> + if (!vms->legacy_smmuv3_present && vms->platform_bus_dev) {
> + PCIBus *bus;
> +
> + bus = PCI_BUS(object_property_get_link(OBJECT(dev), "primary-bus",
> + &error_abort));
> + if (pci_bus_bypass_iommu(bus)) {
> + error_setg(errp, "Bypass option cannot be set for SMMUv3 "
> + "associated PCIe RC");
> + return;
> + }
> +
> + create_smmuv3_dev_dtb(vms, dev, bus);
> + }
> + }
> +
> if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_IOMMU_PCI)) {
> PCIDevice *pdev = PCI_DEVICE(dev);
>
> @@ -3157,6 +3206,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_UEFI_VARS_SYSBUS);
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ARM_SMMUV3);
> #ifdef CONFIG_TPM
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
> #endif
> diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
> index c339a27875..e80776080b 100644
> --- a/hw/core/sysbus-fdt.c
> +++ b/hw/core/sysbus-fdt.c
> @@ -31,6 +31,7 @@
> #include "qemu/error-report.h"
> #include "system/device_tree.h"
> #include "system/tpm.h"
> +#include "hw/arm/smmuv3.h"
> #include "hw/platform-bus.h"
> #include "hw/vfio/vfio-platform.h"
> #include "hw/vfio/vfio-calxeda-xgmac.h"
> @@ -518,6 +519,8 @@ static const BindingEntry bindings[] = {
> #ifdef CONFIG_TPM
> TYPE_BINDING(TYPE_TPM_TIS_SYSBUS, add_tpm_tis_fdt_node),
> #endif
> + /* No generic DT support for smmuv3 dev. Support added for arm virt only */
> + TYPE_BINDING(TYPE_ARM_SMMUV3, no_fdt_node),
> TYPE_BINDING(TYPE_RAMFB_DEVICE, no_fdt_node),
> TYPE_BINDING(TYPE_UEFI_VARS_SYSBUS, add_uefi_vars_node),
> TYPE_BINDING("", NULL), /* last element */
> diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
> index e5e2d09294..80d0fecfde 100644
> --- a/include/hw/arm/smmu-common.h
> +++ b/include/hw/arm/smmu-common.h
> @@ -161,6 +161,7 @@ struct SMMUState {
> QLIST_HEAD(, SMMUDevice) devices_with_notifiers;
> uint8_t bus_num;
> PCIBus *primary_bus;
> + bool smmu_per_bus; /* SMMU is specific to the primary_bus */
> };
>
> struct SMMUBaseClass {
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (6 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:47 ` Jonathan Cameron via
2025-06-27 12:08 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
` (4 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
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
@@ -1226,6 +1226,13 @@ SRST
``aw-bits=val`` (val between 32 and 64, default depends on machine)
This decides the address width of the IOVA address space.
+``-device arm-smmuv3,primary-bus=id``
+ This is only supported by ``-machine virt`` (ARM).
+
+ ``primary-bus=id``
+ Accepts either the default root complex (pcie.0) or a
+ pxb-pcie based root complex.
+
ERST
DEF("name", HAS_ARG, QEMU_OPTION_name,
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device
2025-06-23 9:42 ` [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
@ 2025-06-23 11:47 ` Jonathan Cameron via
2025-06-27 12:08 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:47 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:27 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> Now that arm,virt can have user-creatable smmuv3 devices, document it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> 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
> @@ -1226,6 +1226,13 @@ SRST
> ``aw-bits=val`` (val between 32 and 64, default depends on machine)
> This decides the address width of the IOVA address space.
>
> +``-device arm-smmuv3,primary-bus=id``
> + This is only supported by ``-machine virt`` (ARM).
> +
> + ``primary-bus=id``
> + Accepts either the default root complex (pcie.0) or a
> + pxb-pcie based root complex.
> +
> ERST
>
> DEF("name", HAS_ARG, QEMU_OPTION_name,
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device
2025-06-23 9:42 ` [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
2025-06-23 11:47 ` Jonathan Cameron via
@ 2025-06-27 12:08 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:08 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> Now that arm,virt can have user-creatable smmuv3 devices, document it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
> ---
> 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
> @@ -1226,6 +1226,13 @@ SRST
> ``aw-bits=val`` (val between 32 and 64, default depends on machine)
> This decides the address width of the IOVA address space.
>
> +``-device arm-smmuv3,primary-bus=id``
> + This is only supported by ``-machine virt`` (ARM).
> +
> + ``primary-bus=id``
> + Accepts either the default root complex (pcie.0) or a
> + pxb-pcie based root complex.
> +
> ERST
>
> DEF("name", HAS_ARG, QEMU_OPTION_name,
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data.
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (7 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:49 ` Jonathan Cameron via
2025-06-27 12:14 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
` (3 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
The tests to be added exercises both legacy(iommu=smmuv3) and new
-device arm-smmuv3,.. cases.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
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/data/acpi/aarch64/virt/IORT.smmuv3-legacy | 0
tests/qtest/bios-tables-test-allowed-diff.h | 4 ++++
5 files changed, 4 insertions(+)
create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev b/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..2e3e3ccdce 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,5 @@
/* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy",
+"tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev",
+"tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy",
+"tests/data/acpi/aarch64/virt/IORT.smmuv3-dev",
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data.
2025-06-23 9:42 ` [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
@ 2025-06-23 11:49 ` Jonathan Cameron via
2025-06-27 12:14 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:49 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:28 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> The tests to be added exercises both legacy(iommu=smmuv3) and new
> -device arm-smmuv3,.. cases.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data.
2025-06-23 9:42 ` [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
2025-06-23 11:49 ` Jonathan Cameron via
@ 2025-06-27 12:14 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:14 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
Hi Shameer,
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> The tests to be added exercises both legacy(iommu=smmuv3) and new
Suggesting: exercice. legacy (
Besides:
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
> -device arm-smmuv3,.. cases.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> 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/data/acpi/aarch64/virt/IORT.smmuv3-legacy | 0
> tests/qtest/bios-tables-test-allowed-diff.h | 4 ++++
> 5 files changed, 4 insertions(+)
> create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
> create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
> create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
> create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
>
> diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
> new file mode 100644
> index 0000000000..e69de29bb2
> diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
> new file mode 100644
> index 0000000000..e69de29bb2
> diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev b/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
> new file mode 100644
> index 0000000000..e69de29bb2
> diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
> new file mode 100644
> index 0000000000..e69de29bb2
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
> index dfb8523c8b..2e3e3ccdce 100644
> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> @@ -1 +1,5 @@
> /* List of comma-separated changed AML files to ignore */
> +"tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy",
> +"tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev",
> +"tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy",
> +"tests/data/acpi/aarch64/virt/IORT.smmuv3-dev",
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (8 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 11:57 ` Jonathan Cameron via
2025-06-27 12:34 ` Eric Auger
2025-06-23 9:42 ` [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
` (2 subsequent siblings)
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 remianing one points to ITS.
For the -device arm-smmuv3,... test, the configuration also includes three
Root Complexes, with two connected to separate SMMUv3 devices.
The resulting IORT table contains two SMMUv3 nodes and a Root Complex node
with ID mappings of which two of the ID mappings have output references
pointing to two different SMMUv3 nodes and the remaining ones to ITS.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
tests/qtest/bios-tables-test.c | 86 ++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 0b2bdf9d0d..1c50541b43 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -2231,6 +2231,86 @@ static void test_acpi_aarch64_virt_viot(void)
free_test_data(&data);
}
+static void test_acpi_aarch64_virt_smmuv3_legacy(void)
+{
+ test_data data = {
+ .machine = "virt",
+ .arch = "aarch64",
+ .tcg_only = true,
+ .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
+ .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
+ .ram_start = 0x40000000ULL,
+ .scan_len = 128ULL * MiB,
+ };
+
+ /*
+ * cdrom is plugged into scsi controller to avoid conflict
+ * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb() for
+ * details.
+ *
+ * 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 the ID mappings have output references pointing to the SMMUv3
+ * node and the remaining one points to ITS.
+ */
+ data.variant = ".smmuv3-legacy";
+ test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
+ " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
+ " -drive file="
+ "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2,"
+ "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
+ " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
+ "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
+ " -cpu cortex-a57"
+ " -M iommu=smmuv3"
+ " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
+ " -device pxb-pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20,bypass_iommu=on",
+ &data);
+ free_test_data(&data);
+}
+
+static void test_acpi_aarch64_virt_smmuv3_dev(void)
+{
+ test_data data = {
+ .machine = "virt",
+ .arch = "aarch64",
+ .tcg_only = true,
+ .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
+ .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
+ .ram_start = 0x40000000ULL,
+ .scan_len = 128ULL * MiB,
+ };
+
+ /*
+ * cdrom is plugged into scsi controller to avoid conflict
+ * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb()
+ * for details.
+ *
+ * The setup includes three PCie root complexes, two of which are
+ * connected to separate SMMUv3 devices. The resulting IORT table
+ * contains two SMMUv3 nodes and a Root Complex node with ID mappings
+ * of which two of the ID mappings have output references pointing
+ * to two different SMMUv3 nodes and the remaining ones pointing to
+ * ITS.
+ */
+ data.variant = ".smmuv3-dev";
+ test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
+ " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
+ " -drive file="
+ "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2,"
+ "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
+ " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
+ "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
+ " -cpu cortex-a57"
+ " -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0"
+ " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
+ " -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1"
+ " -device pxb-pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20",
+ &data);
+ free_test_data(&data);
+}
+
#ifndef _WIN32
# define DEV_NULL "/dev/null"
#else
@@ -2586,6 +2666,12 @@ int main(int argc, char *argv[])
if (qtest_has_device("virtio-iommu-pci")) {
qtest_add_func("acpi/virt/viot", test_acpi_aarch64_virt_viot);
}
+ qtest_add_func("acpi/virt/smmuv3-legacy",
+ test_acpi_aarch64_virt_smmuv3_legacy);
+ if (qtest_has_device("arm-smmuv3")) {
+ qtest_add_func("acpi/virt/smmuv3-dev",
+ test_acpi_aarch64_virt_smmuv3_dev);
+ }
}
} else if (strcmp(arch, "riscv64") == 0) {
if (has_tcg && qtest_has_device("virtio-blk-pci")) {
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device
2025-06-23 9:42 ` [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
@ 2025-06-23 11:57 ` Jonathan Cameron via
2025-06-27 12:34 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 11:57 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:29 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 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 remianing one points to ITS.
>
> For the -device arm-smmuv3,... test, the configuration also includes three
> Root Complexes, with two connected to separate SMMUv3 devices.
> The resulting IORT table contains two SMMUv3 nodes and a Root Complex node
> with ID mappings of which two of the ID mappings have output references
> pointing to two different SMMUv3 nodes and the remaining ones to ITS.
>
In the ideal world I think you'd introduce the legacy test at the start of this
series so that we can verify nothing changed, then bring only the test for
the new stuff at the end. Meh. I don't care that much as it's good to have tests
either way.
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device
2025-06-23 9:42 ` [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
2025-06-23 11:57 ` Jonathan Cameron via
@ 2025-06-27 12:34 ` Eric Auger
2025-06-30 7:08 ` Shameerali Kolothum Thodi via
1 sibling, 1 reply; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:34 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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 remianing one points to ITS.
remaining
>
> For the -device arm-smmuv3,... test, the configuration also includes three
> Root Complexes, with two connected to separate SMMUv3 devices.
By the way I have never paid attention to the fact there is only 1
single IORT node despite we have 3 GPEX/PXB devices
> The resulting IORT table contains two SMMUv3 nodes and a Root Complex node
> with ID mappings of which two of the ID mappings have output references
above is a bit difficult to parse.
Suggesting:
The resulting IORT table contains 1 RC node, 2 SMMU nodes and 1 ITS node.
> pointing to two different SMMUv3 nodes and the remaining ones to ITS.
RC node features 3 ID mappings. 2 of them target the 2 SMMU nodes while
the last one targets the ITS.
a drawing might be simpler
pcie.0 -> {SMMU0} -> {ITS}
{RC} pcie.1 -> {SMMU1} -> {ITS}
pcie.2 -> {ITS}
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> tests/qtest/bios-tables-test.c | 86 ++++++++++++++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
>
> diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> index 0b2bdf9d0d..1c50541b43 100644
> --- a/tests/qtest/bios-tables-test.c
> +++ b/tests/qtest/bios-tables-test.c
> @@ -2231,6 +2231,86 @@ static void test_acpi_aarch64_virt_viot(void)
> free_test_data(&data);
> }
>
> +static void test_acpi_aarch64_virt_smmuv3_legacy(void)
> +{
> + test_data data = {
> + .machine = "virt",
> + .arch = "aarch64",
> + .tcg_only = true,
> + .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> + .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> + .ram_start = 0x40000000ULL,
> + .scan_len = 128ULL * MiB,
> + };
> +
> + /*
> + * cdrom is plugged into scsi controller to avoid conflict
> + * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb() for
> + * details.
> + *
> + * 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 the ID mappings have output references pointing to the SMMUv3
> + * node and the remaining one points to ITS.
> + */
> + data.variant = ".smmuv3-legacy";
> + test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
> + " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
> + " -drive file="
> + "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2,"
> + "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
> + " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
> + "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
> + " -cpu cortex-a57"
> + " -M iommu=smmuv3"
> + " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
> + " -device pxb-pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20,bypass_iommu=on",
> + &data);
> + free_test_data(&data);
> +}
> +
> +static void test_acpi_aarch64_virt_smmuv3_dev(void)
> +{
> + test_data data = {
> + .machine = "virt",
> + .arch = "aarch64",
> + .tcg_only = true,
> + .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> + .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> + .ram_start = 0x40000000ULL,
> + .scan_len = 128ULL * MiB,
> + };
> +
> + /*
> + * cdrom is plugged into scsi controller to avoid conflict
> + * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb()
> + * for details.
> + *
> + * The setup includes three PCie root complexes, two of which are
> + * connected to separate SMMUv3 devices. The resulting IORT table
> + * contains two SMMUv3 nodes and a Root Complex node with ID mappings
> + * of which two of the ID mappings have output references pointing
> + * to two different SMMUv3 nodes and the remaining ones pointing to
> + * ITS.
> + */
> + data.variant = ".smmuv3-dev";
> + test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
> + " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
> + " -drive file="
> + "tests/data/uefi-boot-images/bios-tables-test.aarch64.iso.qcow2,"
> + "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
> + " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
> + "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
> + " -cpu cortex-a57"
> + " -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0"
> + " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
> + " -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1"
> + " -device pxb-pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20",
> + &data);
> + free_test_data(&data);
> +}
> +
> #ifndef _WIN32
> # define DEV_NULL "/dev/null"
> #else
> @@ -2586,6 +2666,12 @@ int main(int argc, char *argv[])
> if (qtest_has_device("virtio-iommu-pci")) {
> qtest_add_func("acpi/virt/viot", test_acpi_aarch64_virt_viot);
> }
> + qtest_add_func("acpi/virt/smmuv3-legacy",
> + test_acpi_aarch64_virt_smmuv3_legacy);
> + if (qtest_has_device("arm-smmuv3")) {
> + qtest_add_func("acpi/virt/smmuv3-dev",
> + test_acpi_aarch64_virt_smmuv3_dev);
> + }
> }
> } else if (strcmp(arch, "riscv64") == 0) {
> if (has_tcg && qtest_has_device("virtio-blk-pci")) {
Besides
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device
2025-06-27 12:34 ` Eric Auger
@ 2025-06-30 7:08 ` Shameerali Kolothum Thodi via
0 siblings, 0 replies; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-06-30 7:08 UTC (permalink / raw)
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, June 27, 2025 1:34 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy
> smmuv3 and smmuv3 device
>
>
>
> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> > 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 remianing one points to ITS.
> remaining
> >
> > For the -device arm-smmuv3,... test, the configuration also includes three
> > Root Complexes, with two connected to separate SMMUv3 devices.
> By the way I have never paid attention to the fact there is only 1
> single IORT node despite we have 3 GPEX/PXB devices
> > The resulting IORT table contains two SMMUv3 nodes and a Root
> Complex node
> > with ID mappings of which two of the ID mappings have output references
> above is a bit difficult to parse.
>
> Suggesting:
> The resulting IORT table contains 1 RC node, 2 SMMU nodes and 1 ITS
> node.
>
> > pointing to two different SMMUv3 nodes and the remaining ones to ITS.
> RC node features 3 ID mappings. 2 of them target the 2 SMMU nodes while
> the last one targets the ITS.
> a drawing might be simpler
> pcie.0 -> {SMMU0} -> {ITS}
> {RC} pcie.1 -> {SMMU1} -> {ITS}
> pcie.2 -> {ITS}
Ok . Will rephrase the above.
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> > tests/qtest/bios-tables-test.c | 86
> ++++++++++++++++++++++++++++++++++
> > 1 file changed, 86 insertions(+)
> >
> > diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
> > index 0b2bdf9d0d..1c50541b43 100644
> > --- a/tests/qtest/bios-tables-test.c
> > +++ b/tests/qtest/bios-tables-test.c
> > @@ -2231,6 +2231,86 @@ static void test_acpi_aarch64_virt_viot(void)
> > free_test_data(&data);
> > }
> >
> > +static void test_acpi_aarch64_virt_smmuv3_legacy(void)
> > +{
> > + test_data data = {
> > + .machine = "virt",
> > + .arch = "aarch64",
> > + .tcg_only = true,
> > + .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > + .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > + .ram_start = 0x40000000ULL,
> > + .scan_len = 128ULL * MiB,
> > + };
> > +
> > + /*
> > + * cdrom is plugged into scsi controller to avoid conflict
> > + * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb()
> for
> > + * details.
> > + *
> > + * 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 the ID mappings have output references pointing to the SMMUv3
> > + * node and the remaining one points to ITS.
> > + */
> > + data.variant = ".smmuv3-legacy";
> > + test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
> > + " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
> > + " -drive file="
> > + "tests/data/uefi-boot-images/bios-tables-
> test.aarch64.iso.qcow2,"
> > + "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
> > + " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
> > + "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
> > + " -cpu cortex-a57"
> > + " -M iommu=smmuv3"
> > + " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
> > + " -device pxb-
> pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20,bypass_iommu=on",
> > + &data);
> > + free_test_data(&data);
> > +}
> > +
> > +static void test_acpi_aarch64_virt_smmuv3_dev(void)
> > +{
> > + test_data data = {
> > + .machine = "virt",
> > + .arch = "aarch64",
> > + .tcg_only = true,
> > + .uefi_fl1 = "pc-bios/edk2-aarch64-code.fd",
> > + .uefi_fl2 = "pc-bios/edk2-arm-vars.fd",
> > + .ram_start = 0x40000000ULL,
> > + .scan_len = 128ULL * MiB,
> > + };
> > +
> > + /*
> > + * cdrom is plugged into scsi controller to avoid conflict
> > + * with pxb-pcie. See comments in test_acpi_aarch64_virt_tcg_pxb()
> > + * for details.
> > + *
> > + * The setup includes three PCie root complexes, two of which are
> > + * connected to separate SMMUv3 devices. The resulting IORT table
> > + * contains two SMMUv3 nodes and a Root Complex node with ID
> mappings
> > + * of which two of the ID mappings have output references pointing
> > + * to two different SMMUv3 nodes and the remaining ones pointing to
> > + * ITS.
> > + */
> > + data.variant = ".smmuv3-dev";
> > + test_acpi_one(" -device pcie-root-port,chassis=1,id=pci.1"
> > + " -device virtio-scsi-pci,id=scsi0,bus=pci.1"
> > + " -drive file="
> > + "tests/data/uefi-boot-images/bios-tables-
> test.aarch64.iso.qcow2,"
> > + "if=none,media=cdrom,id=drive-scsi0-0-0-1,readonly=on"
> > + " -device scsi-cd,bus=scsi0.0,scsi-id=0,"
> > + "drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1"
> > + " -cpu cortex-a57"
> > + " -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0"
> > + " -device pxb-pcie,id=pcie.1,bus=pcie.0,bus_nr=0x10"
> > + " -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1"
> > + " -device pxb-pcie,id=pcie.2,bus=pcie.0,bus_nr=0x20",
> > + &data);
> > + free_test_data(&data);
> > +}
> > +
> > #ifndef _WIN32
> > # define DEV_NULL "/dev/null"
> > #else
> > @@ -2586,6 +2666,12 @@ int main(int argc, char *argv[])
> > if (qtest_has_device("virtio-iommu-pci")) {
> > qtest_add_func("acpi/virt/viot", test_acpi_aarch64_virt_viot);
> > }
> > + qtest_add_func("acpi/virt/smmuv3-legacy",
> > + test_acpi_aarch64_virt_smmuv3_legacy);
> > + if (qtest_has_device("arm-smmuv3")) {
> > + qtest_add_func("acpi/virt/smmuv3-dev",
> > + test_acpi_aarch64_virt_smmuv3_dev);
> > + }
> > }
> > } else if (strcmp(arch, "riscv64") == 0) {
> > if (has_tcg && qtest_has_device("virtio-blk-pci")) {
> Besides
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Thanks,
Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (9 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
@ 2025-06-23 9:42 ` Shameer Kolothum via
2025-06-23 12:00 ` Jonathan Cameron via
2025-06-27 12:36 ` Eric Auger
2025-06-27 12:36 ` [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Eric Auger
2025-07-02 1:01 ` Nathan Chen
12 siblings, 2 replies; 39+ messages in thread
From: Shameer Kolothum via @ 2025-06-23 9:42 UTC (permalink / raw)
To: qemu-arm, qemu-devel
Cc: eric.auger, peter.maydell, jgg, nicolinc, ddutile, berrange,
imammedo, nathanc, mochs, smostafa, gustavo.romero, linuxarm,
wangzhou1, jiangkunkun, jonathan.cameron, zhangfei.gao
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 0051 1] Revision : 01
[034h 0052 4] Identifier : 00000000
[038h 0056 4] Mapping Count : 00000000
[03Ch 0060 4] Mapping Offset : 00000000
[040h 0064 4] ItsCount : 00000001
[044h 0068 4] Identifiers : 00000000
[048h 0072 1] Type : 04
[049h 0073 2] Length : 0058
[04Bh 0075 1] Revision : 04
[04Ch 0076 4] Identifier : 00000001
[050h 0080 4] Mapping Count : 00000001
[054h 0084 4] Mapping Offset : 00000044
[058h 0088 8] Base Address : 0000000009050000
[060h 0096 4] Flags (decoded below) : 00000001
COHACC Override : 1
HTTU Override : 0
Proximity Domain Valid : 0
[064h 0100 4] Reserved : 00000000
[068h 0104 8] VATOS Address : 0000000000000000
[070h 0112 4] Model : 00000000
[074h 0116 4] Event GSIV : 0000006A
[078h 0120 4] PRI GSIV : 0000006B
[07Ch 0124 4] GERR GSIV : 0000006D
[080h 0128 4] Sync GSIV : 0000006C
[084h 0132 4] Proximity Domain : 00000000
[088h 0136 4] Device ID Mapping Index : 00000000
[08Ch 0140 4] Input base : 00000000
[090h 0144 4] ID Count : 0000FFFF
[094h 0148 4] Output Base : 00000000
[098h 0152 4] Output Reference : 00000030
[09Ch 0156 4] Flags (decoded below) : 00000000
Single Mapping : 0
[0A0h 0160 1] Type : 02
[0A1h 0161 2] Length : 0074
[0A3h 0163 1] Revision : 03
[0A4h 0164 4] Identifier : 00000002
[0A8h 0168 4] Mapping Count : 00000004
[0ACh 0172 4] Mapping Offset : 00000024
[0B0h 0176 8] Memory Properties : [IORT Memory Access Properties]
[0B0h 0176 4] Cache Coherency : 00000001
[0B4h 0180 1] Hints (decoded below) : 00
Transient : 0
Write Allocate : 0
Read Allocate : 0
Override : 0
[0B5h 0181 2] Reserved : 0000
[0B7h 0183 1] Memory Flags (decoded below) : 03
Coherency : 1
Device Attribute : 1
[0B8h 0184 4] ATS Attribute : 00000000
[0BCh 0188 4] PCI Segment Number : 00000000
[0C0h 0192 1] Memory Size Limit : 40
[0C1h 0193 2] PASID Capabilities : 0000
[0C3h 0195 1] Reserved : 00
[0C4h 0196 4] Input base : 00000000
[0C8h 0200 4] ID Count : 000001FF
[0CCh 0204 4] Output Base : 00000000
[0D0h 0208 4] Output Reference : 00000048
[0D4h 0212 4] Flags (decoded below) : 00000000
Single Mapping : 0
[0D8h 0216 4] Input base : 00001000
[0DCh 0220 4] ID Count : 000000FF
[0E0h 0224 4] Output Base : 00001000
[0E4h 0228 4] Output Reference : 00000048
[0E8h 0232 4] Flags (decoded below) : 00000000
Single Mapping : 0
[0ECh 0236 4] Input base : 00000200
[0F0h 0240 4] ID Count : 00000DFF
[0F4h 0244 4] Output Base : 00000200
[0F8h 0248 4] Output Reference : 00000030
[0FCh 0252 4] Flags (decoded below) : 00000000
Single Mapping : 0
[100h 0256 4] Input base : 00001100
[104h 0260 4] ID Count : 0000EEFF
[108h 0264 4] Output Base : 00001100
[10Ch 0268 4] Output Reference : 00000030
[110h 0272 4] Flags (decoded below) : 00000000
Single Mapping : 0
For the smmuv3-dev test case, IORT has two SMMUV3 nodes and
a Root Complex node with ID mappings of which two points
to two different SMMUv3 nodes and remianining ones pointing
to ITS.
...
[030h 0048 1] Type : 00
[031h 0049 2] Length : 0018
[033h 0051 1] Revision : 01
[034h 0052 4] Identifier : 00000000
[038h 0056 4] Mapping Count : 00000000
[03Ch 0060 4] Mapping Offset : 00000000
[040h 0064 4] ItsCount : 00000001
[044h 0068 4] Identifiers : 00000000
[048h 0072 1] Type : 04
[049h 0073 2] Length : 0058
[04Bh 0075 1] Revision : 04
[04Ch 0076 4] Identifier : 00000001
[050h 0080 4] Mapping Count : 00000001
[054h 0084 4] Mapping Offset : 00000044
[058h 0088 8] Base Address : 000000000C000000
[060h 0096 4] Flags (decoded below) : 00000001
COHACC Override : 1
HTTU Override : 0
Proximity Domain Valid : 0
[064h 0100 4] Reserved : 00000000
[068h 0104 8] VATOS Address : 0000000000000000
[070h 0112 4] Model : 00000000
[074h 0116 4] Event GSIV : 00000090
[078h 0120 4] PRI GSIV : 00000091
[07Ch 0124 4] GERR GSIV : 00000093
[080h 0128 4] Sync GSIV : 00000092
[084h 0132 4] Proximity Domain : 00000000
[088h 0136 4] Device ID Mapping Index : 00000000
[08Ch 0140 4] Input base : 00000000
[090h 0144 4] ID Count : 0000FFFF
[094h 0148 4] Output Base : 00000000
[098h 0152 4] Output Reference : 00000030
[09Ch 0156 4] Flags (decoded below) : 00000000
Single Mapping : 0
[0A0h 0160 1] Type : 04
[0A1h 0161 2] Length : 0058
[0A3h 0163 1] Revision : 04
[0A4h 0164 4] Identifier : 00000002
[0A8h 0168 4] Mapping Count : 00000001
[0ACh 0172 4] Mapping Offset : 00000044
[0B0h 0176 8] Base Address : 000000000C020000
[0B8h 0184 4] Flags (decoded below) : 00000001
COHACC Override : 1
HTTU Override : 0
Proximity Domain Valid : 0
[0BCh 0188 4] Reserved : 00000000
[0C0h 0192 8] VATOS Address : 0000000000000000
[0C8h 0200 4] Model : 00000000
[0CCh 0204 4] Event GSIV : 00000094
[0D0h 0208 4] PRI GSIV : 00000095
[0D4h 0212 4] GERR GSIV : 00000097
[0D8h 0216 4] Sync GSIV : 00000096
[0DCh 0220 4] Proximity Domain : 00000000
[0E0h 0224 4] Device ID Mapping Index : 00000000
[0E4h 0228 4] Input base : 00000000
[0E8h 0232 4] ID Count : 0000FFFF
[0ECh 0236 4] Output Base : 00000000
[0F0h 0240 4] Output Reference : 00000030
[0F4h 0244 4] Flags (decoded below) : 00000000
Single Mapping : 0
[0F8h 0248 1] Type : 02
[0F9h 0249 2] Length : 0074
[0FBh 0251 1] Revision : 03
[0FCh 0252 4] Identifier : 00000003
[100h 0256 4] Mapping Count : 00000004
[104h 0260 4] Mapping Offset : 00000024
[108h 0264 8] Memory Properties : [IORT Memory Access Properties]
[108h 0264 4] Cache Coherency : 00000001
[10Ch 0268 1] Hints (decoded below) : 00
Transient : 0
Write Allocate : 0
Read Allocate : 0
Override : 0
[10Dh 0269 2] Reserved : 0000
[10Fh 0271 1] Memory Flags (decoded below) : 03
Coherency : 1
Device Attribute : 1
[110h 0272 4] ATS Attribute : 00000000
[114h 0276 4] PCI Segment Number : 00000000
[118h 0280 1] Memory Size Limit : 40
[119h 0281 2] PASID Capabilities : 0000
[11Bh 0283 1] Reserved : 00
[11Ch 0284 4] Input base : 00000000
[120h 0288 4] ID Count : 000001FF
[124h 0292 4] Output Base : 00000000
[128h 0296 4] Output Reference : 00000048
[12Ch 0300 4] Flags (decoded below) : 00000000
Single Mapping : 0
[130h 0304 4] Input base : 00001000
[134h 0308 4] ID Count : 000000FF
[138h 0312 4] Output Base : 00001000
[13Ch 0316 4] Output Reference : 000000A0
[140h 0320 4] Flags (decoded below) : 00000000
Single Mapping : 0
[144h 0324 4] Input base : 00000200
[148h 0328 4] ID Count : 00000DFF
[14Ch 0332 4] Output Base : 00000200
[150h 0336 4] Output Reference : 00000030
[154h 0340 4] Flags (decoded below) : 00000000
Single Mapping : 0
[158h 0344 4] Input base : 00001100
[15Ch 0348 4] ID Count : 0000EEFF
[160h 0352 4] Output Base : 00001100
[164h 0356 4] Output Reference : 00000030
[168h 0360 4] Flags (decoded below) : 00000000
Single Mapping : 0
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev | Bin 0 -> 10162 bytes
tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy | Bin 0 -> 10162 bytes
tests/data/acpi/aarch64/virt/IORT.smmuv3-dev | Bin 0 -> 364 bytes
tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy | Bin 0 -> 276 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 4 ----
5 files changed, 4 deletions(-)
diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..4b166b836e75f0c049c245b0c1dc7955f0dbcd04 100644
GIT binary patch
literal 10162
zcmds-OK)4(6@?Ee+M=!=rrwq;SxTFxZ-bQlP~0SybR}6zC7UJXxPSsMXwjmnCk7f6
zX@df;2We`cgGOk_D&SwxUl5?9&I)wULC2Zo4|G;_uXTB~_JL1}z|bfJOmdU^ti9Id
zq51JrTivb0zkD@>>OVH`<-6VG%^$S$WxG^D2)K{i#_!*+zTN9?_Ku#+=gnrb-rL>V
z8r{g-dsf^E_1^uxt#I_@c7E@me6Dk_+ibR4{paevywe?@&t^Xy3J@F$jSzl!F;prq
zS@la>ySDQn-zjvzzkP7ubXRO`_i!T{w#E5IrH~lU#tMn*(B=NhjoMqC($fCj&OKXt
zLu1cYYIqi^{oze7(JH3L5*YiOL^VjF)tA_Wi<Oi_R!wQtoW_dRSWRjSq%<x%ja9F4
zJ*iPkY1Ey@b+2(Fsc|8tkvWYUUgKs`<6=r<#A)308n==fgDH(Mr*X?`tR*$-DUF8H
zSo0dMCN+jq8WT?ARj1MFzd7P9mSri8DW`GUYb3X6{3a>4`i#@~j@L-<(~*>q%TD7p
zuaVxTqbZGfr}4ViNbl3Jl*WS7c*AR?_vxjS##N{BU9XYer;U`xveQ`i8tHvHp3?Y|
z)7bDD>3uqp(s<cvY<i9KKAlWyyy7%+r?HaWr&B47uQ`n^uaVxT(<zN_IE`(uk=~~>
zDUEMAjUBI%-lwxEjcZQhj@L-<)5|H1rqkH<8tHvHm(o~q8hc(Ny-(*;8rPl1n_eTm
zPp_mjZaR(cd5!cwT}WxHIgNd<k>00^DUI7s<G^XGruXU9l*VgL<F408@6)A}#v4xK
zUSDIcw!c!+NBeHOnKyUN;G=EKGnNgLbH2=eQ+@8Ssf)dCr&~FCLaDx;NXj6@OTC<s
zDjqwNdK0et@195sFygholF%w1i?#aiqFBqI#B05h&?+7~)5<?;=jHz{(AsFO+0n`k
zCW~s-s?E*2*)ow5H{HX|_*^#gD7+tj7?#6U_;L6}csKmWZUdGQ&f1;B$^D;ak0*v}
z!>6YKuSh8FSL}W(OpM_1tcrtD76VqShKbSI$myveY0=lOu*w?8is!h_TFVkEO`p9+
zl0|R7!pgGMFcA~2l`E~pN^`^B0j?|^3<Rt!TL+4j*2<MuVx>9a${JUe4r*Lkwi;IU
zQ*x!1KIerf=LN1Tb6zM`mgcSWIWI;z4cyI7*=iW-b6V+h4n{c#qnv|rPAh%RdX%#s
z<uq*dIj!_LhoYSJm7_R%JS0PLPAh%REXtWhISq4tPAh%R;V9>Dlyf-FX{FCO66G9;
zavB!<oL2grqfyS$DCcOL(@LLnEXp|+<ur`;Ij!_LFGV>oML93UIj!_L?JHlg$GM9e
zQBK2dpVLa8b3Dp99_1X5b6V+hPDD8;qMU~5KBtvF=VX*~GRip_=d{x2oQiTzML7-Y
zeNHQV&gm%Ubd+;C&S|C3ITPiaiE`T40H4!JpK~_KIUD7ijdNP*bJ`bh_j+EAa@yAh
zpVLa8b1up`7v-Fbb6V+h&PO@tqn!3N!{@Zp=e!c-yb|TS66dti=Uj+#E<`!)Yl+Wk
zrO&w-<y?$%F2*^n^f|9aIj=@J?Q4wBX{FD(6y;osaxTR=tt@gDSTdbWd^8%W_TQ0x
z&@S6`#m>ysyZ77eP|puL`(bKlsCTcM*PcEM`PPHh$?o9sPsb;-#?isQR{y=Uu>Pk9
z?`?eY`agg2^kG)Bh84T5+wJNj6wtw)RY-k+t859^CykGf->v-Go@ueWbu#nuaoJZq
z+`yBM(2U2QJ^b@n@i>OGo;{rUc5kbDP&;|4aP#+DfBUq1<5vfNnEmWv?yvd5$<Xo7
z!n5&#N(EPTs>wL3b$-a!YMvXiwayXQTFrArw(`Wq|3fzWwrpnsGrM^qWV2V~4B70E
zmXubtm&zfVrE<u|K7N=~Y@4%@AMq7zbGDY{0A6v2Z0zOADp!^$Lu6wsR}$GY1;{1`
zKsL1!+1SdJL^e$UvdICEO|3*WnJ2Po3Xn|>fNW|dvMDE#O;dnuasXsgE0Im+iENqz
zWRn9Rn_7u%GEZdF6d;=%0NK<^WRrO!o2CHS<N(N~RwA3s6WKHc$R-CsHnkGjWS+>T
zDL^(k0J5o-$R_hdHcbJt$pMf}twc7NC$eb@kWCJNY-%O4$vlxwQ-Ex80Ay1ukxk}_
zY?=aOlLH`|T8V5jPh`^+Ae$Tj+0;s8lX)VWrU2RG0LZ3RBAd(;*)#>nCI>(^wG!E6
zp2(&tKsGr5vZ<BGCi6r#O#!mW0gz3tL^hcxvS|vCO%8x;Y9+GCJdsUPfNXLAWK%1V
zP3DPgngV2#10b7PiEJ`YWYZKNn;Zby)JkNNc_N#p0NLaK$fi~zo6Hm0GzG{e2S7Hp
z64_*)$fhYkHaP&Ysg=kk^F%gH0kX*fkWH;bHkl`~X$p`{4uEWGC9=spkxf&8Y;pi(
zQ!9~8=80^Y0%Vf|Ae&l=Y%)(|!<6Tct%0A^zQD+K_OoMj4$6*$KLz#q&a&ALlf{oY
zk<<&FWwW0t6H+gBmaTbS$hQ8+cD~m?H~PPjt-F24j-8!rvupf%TVUH#w$KiF*t4^1
z%b{uiKHvE^du`6(%?_^M4Zq^{PreQ8TRsPG>^p-uHkPzjEn3SGD?Pli_YB^sTGAR;
zT5DNirMY1*;7twyZ)zpHv6U+cZ<+#llLNq;S_yA5Pk7T5z?&QZ-qcEXlX=3MrU2gL
z0Pv<(!kf$!-ZTa9CI^5wwG!TBp75qAfHye+ys4G&Ci8?hO#!^g0pLxogg2QdylD#H
zO%4EWY9+kMJmF1K0B>>tcvCCkP38%2ngV!}1HhYF32!n_c+(WXn;Zb%)Jk}hdBU5f
z0N&&P@TOM6o6Hm5GzIV`2Y@%V65eE<@TMt%H#q>jsg>|1^Mp4|0ldip;7zTBH<>5A
zX$s&?4ghazCA`Tz;Z0KjZ*l;5Q!C+3<_T|_0(g@Hz?)hLZ!%AK(-gp)901<bN_dlb
z!keZ5-sAxArdGn6%oE-;1@I;ZfH$=g-ejKerYV3oIRLz=mGCC>gf~qAyvYIJO|67C
znJ2ty3gAr+0B>p~yvaP_O;Z4GasYT!E8$J%32&MLc#{Lbn_3BPGEaEZ6u_Gt0N&I}
zc$0a;o2CHX<N)xdR>GUi6W%lh@FoX<H?<PpWS;PbDN~JJzPS;e+5ZZmv2Ird&Fv0m
z@0DlZLa;Z!A>D6nzl>DuE-sDJ)BoU)AMA2^&7P@@*r!@?v7f!{a%#_3!qacMHGKLp
zp2LNeuJHI5@*Lkmt+U;A2$Y{8^J><7?)dOEu%olIu0w-+AZq?~+UDTf*YNjmceb~B
z1@9Gq{MNz`mWEHG_C)_hEPn7EsC>Ox`gprzq-7sD^`WeG^qXOn`F3}Ee|c)LxBb@P
j&?6M@oHUL<cqhZ@rw`i?I-A+!qbGB?<KZ$dW`+L(PyH`>
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..4b166b836e75f0c049c245b0c1dc7955f0dbcd04 100644
GIT binary patch
literal 10162
zcmds-OK)4(6@?Ee+M=!=rrwq;SxTFxZ-bQlP~0SybR}6zC7UJXxPSsMXwjmnCk7f6
zX@df;2We`cgGOk_D&SwxUl5?9&I)wULC2Zo4|G;_uXTB~_JL1}z|bfJOmdU^ti9Id
zq51JrTivb0zkD@>>OVH`<-6VG%^$S$WxG^D2)K{i#_!*+zTN9?_Ku#+=gnrb-rL>V
z8r{g-dsf^E_1^uxt#I_@c7E@me6Dk_+ibR4{paevywe?@&t^Xy3J@F$jSzl!F;prq
zS@la>ySDQn-zjvzzkP7ubXRO`_i!T{w#E5IrH~lU#tMn*(B=NhjoMqC($fCj&OKXt
zLu1cYYIqi^{oze7(JH3L5*YiOL^VjF)tA_Wi<Oi_R!wQtoW_dRSWRjSq%<x%ja9F4
zJ*iPkY1Ey@b+2(Fsc|8tkvWYUUgKs`<6=r<#A)308n==fgDH(Mr*X?`tR*$-DUF8H
zSo0dMCN+jq8WT?ARj1MFzd7P9mSri8DW`GUYb3X6{3a>4`i#@~j@L-<(~*>q%TD7p
zuaVxTqbZGfr}4ViNbl3Jl*WS7c*AR?_vxjS##N{BU9XYer;U`xveQ`i8tHvHp3?Y|
z)7bDD>3uqp(s<cvY<i9KKAlWyyy7%+r?HaWr&B47uQ`n^uaVxT(<zN_IE`(uk=~~>
zDUEMAjUBI%-lwxEjcZQhj@L-<)5|H1rqkH<8tHvHm(o~q8hc(Ny-(*;8rPl1n_eTm
zPp_mjZaR(cd5!cwT}WxHIgNd<k>00^DUI7s<G^XGruXU9l*VgL<F408@6)A}#v4xK
zUSDIcw!c!+NBeHOnKyUN;G=EKGnNgLbH2=eQ+@8Ssf)dCr&~FCLaDx;NXj6@OTC<s
zDjqwNdK0et@195sFygholF%w1i?#aiqFBqI#B05h&?+7~)5<?;=jHz{(AsFO+0n`k
zCW~s-s?E*2*)ow5H{HX|_*^#gD7+tj7?#6U_;L6}csKmWZUdGQ&f1;B$^D;ak0*v}
z!>6YKuSh8FSL}W(OpM_1tcrtD76VqShKbSI$myveY0=lOu*w?8is!h_TFVkEO`p9+
zl0|R7!pgGMFcA~2l`E~pN^`^B0j?|^3<Rt!TL+4j*2<MuVx>9a${JUe4r*Lkwi;IU
zQ*x!1KIerf=LN1Tb6zM`mgcSWIWI;z4cyI7*=iW-b6V+h4n{c#qnv|rPAh%RdX%#s
z<uq*dIj!_LhoYSJm7_R%JS0PLPAh%REXtWhISq4tPAh%R;V9>Dlyf-FX{FCO66G9;
zavB!<oL2grqfyS$DCcOL(@LLnEXp|+<ur`;Ij!_LFGV>oML93UIj!_L?JHlg$GM9e
zQBK2dpVLa8b3Dp99_1X5b6V+hPDD8;qMU~5KBtvF=VX*~GRip_=d{x2oQiTzML7-Y
zeNHQV&gm%Ubd+;C&S|C3ITPiaiE`T40H4!JpK~_KIUD7ijdNP*bJ`bh_j+EAa@yAh
zpVLa8b1up`7v-Fbb6V+h&PO@tqn!3N!{@Zp=e!c-yb|TS66dti=Uj+#E<`!)Yl+Wk
zrO&w-<y?$%F2*^n^f|9aIj=@J?Q4wBX{FD(6y;osaxTR=tt@gDSTdbWd^8%W_TQ0x
z&@S6`#m>ysyZ77eP|puL`(bKlsCTcM*PcEM`PPHh$?o9sPsb;-#?isQR{y=Uu>Pk9
z?`?eY`agg2^kG)Bh84T5+wJNj6wtw)RY-k+t859^CykGf->v-Go@ueWbu#nuaoJZq
z+`yBM(2U2QJ^b@n@i>OGo;{rUc5kbDP&;|4aP#+DfBUq1<5vfNnEmWv?yvd5$<Xo7
z!n5&#N(EPTs>wL3b$-a!YMvXiwayXQTFrArw(`Wq|3fzWwrpnsGrM^qWV2V~4B70E
zmXubtm&zfVrE<u|K7N=~Y@4%@AMq7zbGDY{0A6v2Z0zOADp!^$Lu6wsR}$GY1;{1`
zKsL1!+1SdJL^e$UvdICEO|3*WnJ2Po3Xn|>fNW|dvMDE#O;dnuasXsgE0Im+iENqz
zWRn9Rn_7u%GEZdF6d;=%0NK<^WRrO!o2CHS<N(N~RwA3s6WKHc$R-CsHnkGjWS+>T
zDL^(k0J5o-$R_hdHcbJt$pMf}twc7NC$eb@kWCJNY-%O4$vlxwQ-Ex80Ay1ukxk}_
zY?=aOlLH`|T8V5jPh`^+Ae$Tj+0;s8lX)VWrU2RG0LZ3RBAd(;*)#>nCI>(^wG!E6
zp2(&tKsGr5vZ<BGCi6r#O#!mW0gz3tL^hcxvS|vCO%8x;Y9+GCJdsUPfNXLAWK%1V
zP3DPgngV2#10b7PiEJ`YWYZKNn;Zby)JkNNc_N#p0NLaK$fi~zo6Hm0GzG{e2S7Hp
z64_*)$fhYkHaP&Ysg=kk^F%gH0kX*fkWH;bHkl`~X$p`{4uEWGC9=spkxf&8Y;pi(
zQ!9~8=80^Y0%Vf|Ae&l=Y%)(|!<6Tct%0A^zQD+K_OoMj4$6*$KLz#q&a&ALlf{oY
zk<<&FWwW0t6H+gBmaTbS$hQ8+cD~m?H~PPjt-F24j-8!rvupf%TVUH#w$KiF*t4^1
z%b{uiKHvE^du`6(%?_^M4Zq^{PreQ8TRsPG>^p-uHkPzjEn3SGD?Pli_YB^sTGAR;
zT5DNirMY1*;7twyZ)zpHv6U+cZ<+#llLNq;S_yA5Pk7T5z?&QZ-qcEXlX=3MrU2gL
z0Pv<(!kf$!-ZTa9CI^5wwG!TBp75qAfHye+ys4G&Ci8?hO#!^g0pLxogg2QdylD#H
zO%4EWY9+kMJmF1K0B>>tcvCCkP38%2ngV!}1HhYF32!n_c+(WXn;Zb%)Jk}hdBU5f
z0N&&P@TOM6o6Hm5GzIV`2Y@%V65eE<@TMt%H#q>jsg>|1^Mp4|0ldip;7zTBH<>5A
zX$s&?4ghazCA`Tz;Z0KjZ*l;5Q!C+3<_T|_0(g@Hz?)hLZ!%AK(-gp)901<bN_dlb
z!keZ5-sAxArdGn6%oE-;1@I;ZfH$=g-ejKerYV3oIRLz=mGCC>gf~qAyvYIJO|67C
znJ2ty3gAr+0B>p~yvaP_O;Z4GasYT!E8$J%32&MLc#{Lbn_3BPGEaEZ6u_Gt0N&I}
zc$0a;o2CHX<N)xdR>GUi6W%lh@FoX<H?<PpWS;PbDN~JJzPS;e+5ZZmv2Ird&Fv0m
z@0DlZLa;Z!A>D6nzl>DuE-sDJ)BoU)AMA2^&7P@@*r!@?v7f!{a%#_3!qacMHGKLp
zp2LNeuJHI5@*Lkmt+U;A2$Y{8^J><7?)dOEu%olIu0w-+AZq?~+UDTf*YNjmceb~B
z1@9Gq{MNz`mWEHG_C)_hEPn7EsC>Ox`gprzq-7sD^`WeG^qXOn`F3}Ee|c)LxBb@P
j&?6M@oHUL<cqhZ@rw`i?I-A+!qbGB?<KZ$dW`+L(PyH`>
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev b/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..67be268f62afbf2d9459540984da5e9340afdaaa 100644
GIT binary patch
literal 364
zcmebD4+_a)WME)E<>c?|5v<@85#X!<1VAAM5F13Z0I>lOgMkDCNC*yK9F_<M77!bR
zT_CbNAPOcA5rU8tfYd}Fo(#m3AVP5R|9=P*W*^90CZG_)Tqd06P64W$3dGZacp4BR
z19WqlN*I`#feJu=QvqVAJ3&HV-~grnLnS<*d<Fpq2Cx%>^a7X|(1HJXfgB(Wb2oz^
MQ0yI03`oPo01?F*0RR91
literal 0
HcmV?d00001
diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..41981a449fc306b80cccd87ddec3c593a8d72c07 100644
GIT binary patch
literal 276
zcmX|*K@NgI3`M`puy8?wi3^u3IDkhWzycE!jI!Vis5{Ti6^7s1@{>QmeVugXHa@5G
z0SNbY?1op>&X2C5h#<9Ops%#*0ztdHi8G?q;$EluQNrhn>{ys@`b&R|d8G8O{Jrdl
mkP$_?rfr{mN!3^;8w}Q?1auX1XIzvDUSRruoXA!(rn3!nx)K2Z
literal 0
HcmV?d00001
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
index 2e3e3ccdce..dfb8523c8b 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1,5 +1 @@
/* List of comma-separated changed AML files to ignore */
-"tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy",
-"tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev",
-"tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy",
-"tests/data/acpi/aarch64/virt/IORT.smmuv3-dev",
--
2.34.1
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests
2025-06-23 9:42 ` [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
@ 2025-06-23 12:00 ` Jonathan Cameron via
2025-06-27 12:36 ` Eric Auger
1 sibling, 0 replies; 39+ messages in thread
From: Jonathan Cameron via @ 2025-06-23 12:00 UTC (permalink / raw)
To: Shameer Kolothum, linuxarm
Cc: qemu-arm, qemu-devel, eric.auger, peter.maydell, jgg, nicolinc,
ddutile, berrange, imammedo, nathanc, mochs, smostafa,
gustavo.romero, wangzhou1, jiangkunkun, jonathan.cameron,
zhangfei.gao
On Mon, 23 Jun 2025 10:42:30 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> 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.
I haven't checked the blobs line by line but looks correct to me.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests
2025-06-23 9:42 ` [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
2025-06-23 12:00 ` Jonathan Cameron via
@ 2025-06-27 12:36 ` Eric Auger
2025-06-30 7:11 ` Shameerali Kolothum Thodi via
1 sibling, 1 reply; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:36 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
Hi Shameer,
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> 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.
You don't describe DSDT at all below, just IORT. I don't know whether it
is mandated though
>
> ...
> [030h 0048 1] Type : 00
> [031h 0049 2] Length : 0018
> [033h 0051 1] Revision : 01
> [034h 0052 4] Identifier : 00000000
> [038h 0056 4] Mapping Count : 00000000
> [03Ch 0060 4] Mapping Offset : 00000000
>
> [040h 0064 4] ItsCount : 00000001
> [044h 0068 4] Identifiers : 00000000
>
> [048h 0072 1] Type : 04
> [049h 0073 2] Length : 0058
> [04Bh 0075 1] Revision : 04
> [04Ch 0076 4] Identifier : 00000001
> [050h 0080 4] Mapping Count : 00000001
> [054h 0084 4] Mapping Offset : 00000044
>
> [058h 0088 8] Base Address : 0000000009050000
> [060h 0096 4] Flags (decoded below) : 00000001
> COHACC Override : 1
> HTTU Override : 0
> Proximity Domain Valid : 0
> [064h 0100 4] Reserved : 00000000
> [068h 0104 8] VATOS Address : 0000000000000000
> [070h 0112 4] Model : 00000000
> [074h 0116 4] Event GSIV : 0000006A
> [078h 0120 4] PRI GSIV : 0000006B
> [07Ch 0124 4] GERR GSIV : 0000006D
> [080h 0128 4] Sync GSIV : 0000006C
> [084h 0132 4] Proximity Domain : 00000000
> [088h 0136 4] Device ID Mapping Index : 00000000
>
> [08Ch 0140 4] Input base : 00000000
> [090h 0144 4] ID Count : 0000FFFF
> [094h 0148 4] Output Base : 00000000
> [098h 0152 4] Output Reference : 00000030
> [09Ch 0156 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [0A0h 0160 1] Type : 02
> [0A1h 0161 2] Length : 0074
> [0A3h 0163 1] Revision : 03
> [0A4h 0164 4] Identifier : 00000002
> [0A8h 0168 4] Mapping Count : 00000004
> [0ACh 0172 4] Mapping Offset : 00000024
>
> [0B0h 0176 8] Memory Properties : [IORT Memory Access Properties]
> [0B0h 0176 4] Cache Coherency : 00000001
> [0B4h 0180 1] Hints (decoded below) : 00
> Transient : 0
> Write Allocate : 0
> Read Allocate : 0
> Override : 0
> [0B5h 0181 2] Reserved : 0000
> [0B7h 0183 1] Memory Flags (decoded below) : 03
> Coherency : 1
> Device Attribute : 1
> [0B8h 0184 4] ATS Attribute : 00000000
> [0BCh 0188 4] PCI Segment Number : 00000000
> [0C0h 0192 1] Memory Size Limit : 40
> [0C1h 0193 2] PASID Capabilities : 0000
> [0C3h 0195 1] Reserved : 00
>
> [0C4h 0196 4] Input base : 00000000
> [0C8h 0200 4] ID Count : 000001FF
> [0CCh 0204 4] Output Base : 00000000
> [0D0h 0208 4] Output Reference : 00000048
> [0D4h 0212 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [0D8h 0216 4] Input base : 00001000
> [0DCh 0220 4] ID Count : 000000FF
> [0E0h 0224 4] Output Base : 00001000
> [0E4h 0228 4] Output Reference : 00000048
> [0E8h 0232 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [0ECh 0236 4] Input base : 00000200
> [0F0h 0240 4] ID Count : 00000DFF
> [0F4h 0244 4] Output Base : 00000200
> [0F8h 0248 4] Output Reference : 00000030
> [0FCh 0252 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [100h 0256 4] Input base : 00001100
> [104h 0260 4] ID Count : 0000EEFF
> [108h 0264 4] Output Base : 00001100
> [10Ch 0268 4] Output Reference : 00000030
> [110h 0272 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> For the smmuv3-dev test case, IORT has two SMMUV3 nodes and
> a Root Complex node with ID mappings of which two points
> to two different SMMUv3 nodes and remianining ones pointing
remaining. Still difficult to parse for me ;-)
Eric
> to ITS.
>
> ...
> [030h 0048 1] Type : 00
> [031h 0049 2] Length : 0018
> [033h 0051 1] Revision : 01
> [034h 0052 4] Identifier : 00000000
> [038h 0056 4] Mapping Count : 00000000
> [03Ch 0060 4] Mapping Offset : 00000000
>
> [040h 0064 4] ItsCount : 00000001
> [044h 0068 4] Identifiers : 00000000
>
> [048h 0072 1] Type : 04
> [049h 0073 2] Length : 0058
> [04Bh 0075 1] Revision : 04
> [04Ch 0076 4] Identifier : 00000001
> [050h 0080 4] Mapping Count : 00000001
> [054h 0084 4] Mapping Offset : 00000044
>
> [058h 0088 8] Base Address : 000000000C000000
> [060h 0096 4] Flags (decoded below) : 00000001
> COHACC Override : 1
> HTTU Override : 0
> Proximity Domain Valid : 0
> [064h 0100 4] Reserved : 00000000
> [068h 0104 8] VATOS Address : 0000000000000000
> [070h 0112 4] Model : 00000000
> [074h 0116 4] Event GSIV : 00000090
> [078h 0120 4] PRI GSIV : 00000091
> [07Ch 0124 4] GERR GSIV : 00000093
> [080h 0128 4] Sync GSIV : 00000092
> [084h 0132 4] Proximity Domain : 00000000
> [088h 0136 4] Device ID Mapping Index : 00000000
>
> [08Ch 0140 4] Input base : 00000000
> [090h 0144 4] ID Count : 0000FFFF
> [094h 0148 4] Output Base : 00000000
> [098h 0152 4] Output Reference : 00000030
> [09Ch 0156 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [0A0h 0160 1] Type : 04
> [0A1h 0161 2] Length : 0058
> [0A3h 0163 1] Revision : 04
> [0A4h 0164 4] Identifier : 00000002
> [0A8h 0168 4] Mapping Count : 00000001
> [0ACh 0172 4] Mapping Offset : 00000044
>
> [0B0h 0176 8] Base Address : 000000000C020000
> [0B8h 0184 4] Flags (decoded below) : 00000001
> COHACC Override : 1
> HTTU Override : 0
> Proximity Domain Valid : 0
> [0BCh 0188 4] Reserved : 00000000
> [0C0h 0192 8] VATOS Address : 0000000000000000
> [0C8h 0200 4] Model : 00000000
> [0CCh 0204 4] Event GSIV : 00000094
> [0D0h 0208 4] PRI GSIV : 00000095
> [0D4h 0212 4] GERR GSIV : 00000097
> [0D8h 0216 4] Sync GSIV : 00000096
> [0DCh 0220 4] Proximity Domain : 00000000
> [0E0h 0224 4] Device ID Mapping Index : 00000000
>
> [0E4h 0228 4] Input base : 00000000
> [0E8h 0232 4] ID Count : 0000FFFF
> [0ECh 0236 4] Output Base : 00000000
> [0F0h 0240 4] Output Reference : 00000030
> [0F4h 0244 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [0F8h 0248 1] Type : 02
> [0F9h 0249 2] Length : 0074
> [0FBh 0251 1] Revision : 03
> [0FCh 0252 4] Identifier : 00000003
> [100h 0256 4] Mapping Count : 00000004
> [104h 0260 4] Mapping Offset : 00000024
>
> [108h 0264 8] Memory Properties : [IORT Memory Access Properties]
> [108h 0264 4] Cache Coherency : 00000001
> [10Ch 0268 1] Hints (decoded below) : 00
> Transient : 0
> Write Allocate : 0
> Read Allocate : 0
> Override : 0
> [10Dh 0269 2] Reserved : 0000
> [10Fh 0271 1] Memory Flags (decoded below) : 03
> Coherency : 1
> Device Attribute : 1
> [110h 0272 4] ATS Attribute : 00000000
> [114h 0276 4] PCI Segment Number : 00000000
> [118h 0280 1] Memory Size Limit : 40
> [119h 0281 2] PASID Capabilities : 0000
> [11Bh 0283 1] Reserved : 00
>
> [11Ch 0284 4] Input base : 00000000
> [120h 0288 4] ID Count : 000001FF
> [124h 0292 4] Output Base : 00000000
> [128h 0296 4] Output Reference : 00000048
> [12Ch 0300 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [130h 0304 4] Input base : 00001000
> [134h 0308 4] ID Count : 000000FF
> [138h 0312 4] Output Base : 00001000
> [13Ch 0316 4] Output Reference : 000000A0
> [140h 0320 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [144h 0324 4] Input base : 00000200
> [148h 0328 4] ID Count : 00000DFF
> [14Ch 0332 4] Output Base : 00000200
> [150h 0336 4] Output Reference : 00000030
> [154h 0340 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> [158h 0344 4] Input base : 00001100
> [15Ch 0348 4] ID Count : 0000EEFF
> [160h 0352 4] Output Base : 00001100
> [164h 0356 4] Output Reference : 00000030
> [168h 0360 4] Flags (decoded below) : 00000000
> Single Mapping : 0
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev | Bin 0 -> 10162 bytes
> tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy | Bin 0 -> 10162 bytes
> tests/data/acpi/aarch64/virt/IORT.smmuv3-dev | Bin 0 -> 364 bytes
> tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy | Bin 0 -> 276 bytes
> tests/qtest/bios-tables-test-allowed-diff.h | 4 ----
> 5 files changed, 4 deletions(-)
>
> diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
> index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..4b166b836e75f0c049c245b0c1dc7955f0dbcd04 100644
> GIT binary patch
> literal 10162
> zcmds-OK)4(6@?Ee+M=!=rrwq;SxTFxZ-bQlP~0SybR}6zC7UJXxPSsMXwjmnCk7f6
> zX@df;2We`cgGOk_D&SwxUl5?9&I)wULC2Zo4|G;_uXTB~_JL1}z|bfJOmdU^ti9Id
> zq51JrTivb0zkD@>>OVH`<-6VG%^$S$WxG^D2)K{i#_!*+zTN9?_Ku#+=gnrb-rL>V
> z8r{g-dsf^E_1^uxt#I_@c7E@me6Dk_+ibR4{paevywe?@&t^Xy3J@F$jSzl!F;prq
> zS@la>ySDQn-zjvzzkP7ubXRO`_i!T{w#E5IrH~lU#tMn*(B=NhjoMqC($fCj&OKXt
> zLu1cYYIqi^{oze7(JH3L5*YiOL^VjF)tA_Wi<Oi_R!wQtoW_dRSWRjSq%<x%ja9F4
> zJ*iPkY1Ey@b+2(Fsc|8tkvWYUUgKs`<6=r<#A)308n==fgDH(Mr*X?`tR*$-DUF8H
> zSo0dMCN+jq8WT?ARj1MFzd7P9mSri8DW`GUYb3X6{3a>4`i#@~j@L-<(~*>q%TD7p
> zuaVxTqbZGfr}4ViNbl3Jl*WS7c*AR?_vxjS##N{BU9XYer;U`xveQ`i8tHvHp3?Y|
> z)7bDD>3uqp(s<cvY<i9KKAlWyyy7%+r?HaWr&B47uQ`n^uaVxT(<zN_IE`(uk=~~>
> zDUEMAjUBI%-lwxEjcZQhj@L-<)5|H1rqkH<8tHvHm(o~q8hc(Ny-(*;8rPl1n_eTm
> zPp_mjZaR(cd5!cwT}WxHIgNd<k>00^DUI7s<G^XGruXU9l*VgL<F408@6)A}#v4xK
> zUSDIcw!c!+NBeHOnKyUN;G=EKGnNgLbH2=eQ+@8Ssf)dCr&~FCLaDx;NXj6@OTC<s
> zDjqwNdK0et@195sFygholF%w1i?#aiqFBqI#B05h&?+7~)5<?;=jHz{(AsFO+0n`k
> zCW~s-s?E*2*)ow5H{HX|_*^#gD7+tj7?#6U_;L6}csKmWZUdGQ&f1;B$^D;ak0*v}
> z!>6YKuSh8FSL}W(OpM_1tcrtD76VqShKbSI$myveY0=lOu*w?8is!h_TFVkEO`p9+
> zl0|R7!pgGMFcA~2l`E~pN^`^B0j?|^3<Rt!TL+4j*2<MuVx>9a${JUe4r*Lkwi;IU
> zQ*x!1KIerf=LN1Tb6zM`mgcSWIWI;z4cyI7*=iW-b6V+h4n{c#qnv|rPAh%RdX%#s
> z<uq*dIj!_LhoYSJm7_R%JS0PLPAh%REXtWhISq4tPAh%R;V9>Dlyf-FX{FCO66G9;
> zavB!<oL2grqfyS$DCcOL(@LLnEXp|+<ur`;Ij!_LFGV>oML93UIj!_L?JHlg$GM9e
> zQBK2dpVLa8b3Dp99_1X5b6V+hPDD8;qMU~5KBtvF=VX*~GRip_=d{x2oQiTzML7-Y
> zeNHQV&gm%Ubd+;C&S|C3ITPiaiE`T40H4!JpK~_KIUD7ijdNP*bJ`bh_j+EAa@yAh
> zpVLa8b1up`7v-Fbb6V+h&PO@tqn!3N!{@Zp=e!c-yb|TS66dti=Uj+#E<`!)Yl+Wk
> zrO&w-<y?$%F2*^n^f|9aIj=@J?Q4wBX{FD(6y;osaxTR=tt@gDSTdbWd^8%W_TQ0x
> z&@S6`#m>ysyZ77eP|puL`(bKlsCTcM*PcEM`PPHh$?o9sPsb;-#?isQR{y=Uu>Pk9
> z?`?eY`agg2^kG)Bh84T5+wJNj6wtw)RY-k+t859^CykGf->v-Go@ueWbu#nuaoJZq
> z+`yBM(2U2QJ^b@n@i>OGo;{rUc5kbDP&;|4aP#+DfBUq1<5vfNnEmWv?yvd5$<Xo7
> z!n5&#N(EPTs>wL3b$-a!YMvXiwayXQTFrArw(`Wq|3fzWwrpnsGrM^qWV2V~4B70E
> zmXubtm&zfVrE<u|K7N=~Y@4%@AMq7zbGDY{0A6v2Z0zOADp!^$Lu6wsR}$GY1;{1`
> zKsL1!+1SdJL^e$UvdICEO|3*WnJ2Po3Xn|>fNW|dvMDE#O;dnuasXsgE0Im+iENqz
> zWRn9Rn_7u%GEZdF6d;=%0NK<^WRrO!o2CHS<N(N~RwA3s6WKHc$R-CsHnkGjWS+>T
> zDL^(k0J5o-$R_hdHcbJt$pMf}twc7NC$eb@kWCJNY-%O4$vlxwQ-Ex80Ay1ukxk}_
> zY?=aOlLH`|T8V5jPh`^+Ae$Tj+0;s8lX)VWrU2RG0LZ3RBAd(;*)#>nCI>(^wG!E6
> zp2(&tKsGr5vZ<BGCi6r#O#!mW0gz3tL^hcxvS|vCO%8x;Y9+GCJdsUPfNXLAWK%1V
> zP3DPgngV2#10b7PiEJ`YWYZKNn;Zby)JkNNc_N#p0NLaK$fi~zo6Hm0GzG{e2S7Hp
> z64_*)$fhYkHaP&Ysg=kk^F%gH0kX*fkWH;bHkl`~X$p`{4uEWGC9=spkxf&8Y;pi(
> zQ!9~8=80^Y0%Vf|Ae&l=Y%)(|!<6Tct%0A^zQD+K_OoMj4$6*$KLz#q&a&ALlf{oY
> zk<<&FWwW0t6H+gBmaTbS$hQ8+cD~m?H~PPjt-F24j-8!rvupf%TVUH#w$KiF*t4^1
> z%b{uiKHvE^du`6(%?_^M4Zq^{PreQ8TRsPG>^p-uHkPzjEn3SGD?Pli_YB^sTGAR;
> zT5DNirMY1*;7twyZ)zpHv6U+cZ<+#llLNq;S_yA5Pk7T5z?&QZ-qcEXlX=3MrU2gL
> z0Pv<(!kf$!-ZTa9CI^5wwG!TBp75qAfHye+ys4G&Ci8?hO#!^g0pLxogg2QdylD#H
> zO%4EWY9+kMJmF1K0B>>tcvCCkP38%2ngV!}1HhYF32!n_c+(WXn;Zb%)Jk}hdBU5f
> z0N&&P@TOM6o6Hm5GzIV`2Y@%V65eE<@TMt%H#q>jsg>|1^Mp4|0ldip;7zTBH<>5A
> zX$s&?4ghazCA`Tz;Z0KjZ*l;5Q!C+3<_T|_0(g@Hz?)hLZ!%AK(-gp)901<bN_dlb
> z!keZ5-sAxArdGn6%oE-;1@I;ZfH$=g-ejKerYV3oIRLz=mGCC>gf~qAyvYIJO|67C
> znJ2ty3gAr+0B>p~yvaP_O;Z4GasYT!E8$J%32&MLc#{Lbn_3BPGEaEZ6u_Gt0N&I}
> zc$0a;o2CHX<N)xdR>GUi6W%lh@FoX<H?<PpWS;PbDN~JJzPS;e+5ZZmv2Ird&Fv0m
> z@0DlZLa;Z!A>D6nzl>DuE-sDJ)BoU)AMA2^&7P@@*r!@?v7f!{a%#_3!qacMHGKLp
> zp2LNeuJHI5@*Lkmt+U;A2$Y{8^J><7?)dOEu%olIu0w-+AZq?~+UDTf*YNjmceb~B
> z1@9Gq{MNz`mWEHG_C)_hEPn7EsC>Ox`gprzq-7sD^`WeG^qXOn`F3}Ee|c)LxBb@P
> j&?6M@oHUL<cqhZ@rw`i?I-A+!qbGB?<KZ$dW`+L(PyH`>
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
> index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..4b166b836e75f0c049c245b0c1dc7955f0dbcd04 100644
> GIT binary patch
> literal 10162
> zcmds-OK)4(6@?Ee+M=!=rrwq;SxTFxZ-bQlP~0SybR}6zC7UJXxPSsMXwjmnCk7f6
> zX@df;2We`cgGOk_D&SwxUl5?9&I)wULC2Zo4|G;_uXTB~_JL1}z|bfJOmdU^ti9Id
> zq51JrTivb0zkD@>>OVH`<-6VG%^$S$WxG^D2)K{i#_!*+zTN9?_Ku#+=gnrb-rL>V
> z8r{g-dsf^E_1^uxt#I_@c7E@me6Dk_+ibR4{paevywe?@&t^Xy3J@F$jSzl!F;prq
> zS@la>ySDQn-zjvzzkP7ubXRO`_i!T{w#E5IrH~lU#tMn*(B=NhjoMqC($fCj&OKXt
> zLu1cYYIqi^{oze7(JH3L5*YiOL^VjF)tA_Wi<Oi_R!wQtoW_dRSWRjSq%<x%ja9F4
> zJ*iPkY1Ey@b+2(Fsc|8tkvWYUUgKs`<6=r<#A)308n==fgDH(Mr*X?`tR*$-DUF8H
> zSo0dMCN+jq8WT?ARj1MFzd7P9mSri8DW`GUYb3X6{3a>4`i#@~j@L-<(~*>q%TD7p
> zuaVxTqbZGfr}4ViNbl3Jl*WS7c*AR?_vxjS##N{BU9XYer;U`xveQ`i8tHvHp3?Y|
> z)7bDD>3uqp(s<cvY<i9KKAlWyyy7%+r?HaWr&B47uQ`n^uaVxT(<zN_IE`(uk=~~>
> zDUEMAjUBI%-lwxEjcZQhj@L-<)5|H1rqkH<8tHvHm(o~q8hc(Ny-(*;8rPl1n_eTm
> zPp_mjZaR(cd5!cwT}WxHIgNd<k>00^DUI7s<G^XGruXU9l*VgL<F408@6)A}#v4xK
> zUSDIcw!c!+NBeHOnKyUN;G=EKGnNgLbH2=eQ+@8Ssf)dCr&~FCLaDx;NXj6@OTC<s
> zDjqwNdK0et@195sFygholF%w1i?#aiqFBqI#B05h&?+7~)5<?;=jHz{(AsFO+0n`k
> zCW~s-s?E*2*)ow5H{HX|_*^#gD7+tj7?#6U_;L6}csKmWZUdGQ&f1;B$^D;ak0*v}
> z!>6YKuSh8FSL}W(OpM_1tcrtD76VqShKbSI$myveY0=lOu*w?8is!h_TFVkEO`p9+
> zl0|R7!pgGMFcA~2l`E~pN^`^B0j?|^3<Rt!TL+4j*2<MuVx>9a${JUe4r*Lkwi;IU
> zQ*x!1KIerf=LN1Tb6zM`mgcSWIWI;z4cyI7*=iW-b6V+h4n{c#qnv|rPAh%RdX%#s
> z<uq*dIj!_LhoYSJm7_R%JS0PLPAh%REXtWhISq4tPAh%R;V9>Dlyf-FX{FCO66G9;
> zavB!<oL2grqfyS$DCcOL(@LLnEXp|+<ur`;Ij!_LFGV>oML93UIj!_L?JHlg$GM9e
> zQBK2dpVLa8b3Dp99_1X5b6V+hPDD8;qMU~5KBtvF=VX*~GRip_=d{x2oQiTzML7-Y
> zeNHQV&gm%Ubd+;C&S|C3ITPiaiE`T40H4!JpK~_KIUD7ijdNP*bJ`bh_j+EAa@yAh
> zpVLa8b1up`7v-Fbb6V+h&PO@tqn!3N!{@Zp=e!c-yb|TS66dti=Uj+#E<`!)Yl+Wk
> zrO&w-<y?$%F2*^n^f|9aIj=@J?Q4wBX{FD(6y;osaxTR=tt@gDSTdbWd^8%W_TQ0x
> z&@S6`#m>ysyZ77eP|puL`(bKlsCTcM*PcEM`PPHh$?o9sPsb;-#?isQR{y=Uu>Pk9
> z?`?eY`agg2^kG)Bh84T5+wJNj6wtw)RY-k+t859^CykGf->v-Go@ueWbu#nuaoJZq
> z+`yBM(2U2QJ^b@n@i>OGo;{rUc5kbDP&;|4aP#+DfBUq1<5vfNnEmWv?yvd5$<Xo7
> z!n5&#N(EPTs>wL3b$-a!YMvXiwayXQTFrArw(`Wq|3fzWwrpnsGrM^qWV2V~4B70E
> zmXubtm&zfVrE<u|K7N=~Y@4%@AMq7zbGDY{0A6v2Z0zOADp!^$Lu6wsR}$GY1;{1`
> zKsL1!+1SdJL^e$UvdICEO|3*WnJ2Po3Xn|>fNW|dvMDE#O;dnuasXsgE0Im+iENqz
> zWRn9Rn_7u%GEZdF6d;=%0NK<^WRrO!o2CHS<N(N~RwA3s6WKHc$R-CsHnkGjWS+>T
> zDL^(k0J5o-$R_hdHcbJt$pMf}twc7NC$eb@kWCJNY-%O4$vlxwQ-Ex80Ay1ukxk}_
> zY?=aOlLH`|T8V5jPh`^+Ae$Tj+0;s8lX)VWrU2RG0LZ3RBAd(;*)#>nCI>(^wG!E6
> zp2(&tKsGr5vZ<BGCi6r#O#!mW0gz3tL^hcxvS|vCO%8x;Y9+GCJdsUPfNXLAWK%1V
> zP3DPgngV2#10b7PiEJ`YWYZKNn;Zby)JkNNc_N#p0NLaK$fi~zo6Hm0GzG{e2S7Hp
> z64_*)$fhYkHaP&Ysg=kk^F%gH0kX*fkWH;bHkl`~X$p`{4uEWGC9=spkxf&8Y;pi(
> zQ!9~8=80^Y0%Vf|Ae&l=Y%)(|!<6Tct%0A^zQD+K_OoMj4$6*$KLz#q&a&ALlf{oY
> zk<<&FWwW0t6H+gBmaTbS$hQ8+cD~m?H~PPjt-F24j-8!rvupf%TVUH#w$KiF*t4^1
> z%b{uiKHvE^du`6(%?_^M4Zq^{PreQ8TRsPG>^p-uHkPzjEn3SGD?Pli_YB^sTGAR;
> zT5DNirMY1*;7twyZ)zpHv6U+cZ<+#llLNq;S_yA5Pk7T5z?&QZ-qcEXlX=3MrU2gL
> z0Pv<(!kf$!-ZTa9CI^5wwG!TBp75qAfHye+ys4G&Ci8?hO#!^g0pLxogg2QdylD#H
> zO%4EWY9+kMJmF1K0B>>tcvCCkP38%2ngV!}1HhYF32!n_c+(WXn;Zb%)Jk}hdBU5f
> z0N&&P@TOM6o6Hm5GzIV`2Y@%V65eE<@TMt%H#q>jsg>|1^Mp4|0ldip;7zTBH<>5A
> zX$s&?4ghazCA`Tz;Z0KjZ*l;5Q!C+3<_T|_0(g@Hz?)hLZ!%AK(-gp)901<bN_dlb
> z!keZ5-sAxArdGn6%oE-;1@I;ZfH$=g-ejKerYV3oIRLz=mGCC>gf~qAyvYIJO|67C
> znJ2ty3gAr+0B>p~yvaP_O;Z4GasYT!E8$J%32&MLc#{Lbn_3BPGEaEZ6u_Gt0N&I}
> zc$0a;o2CHX<N)xdR>GUi6W%lh@FoX<H?<PpWS;PbDN~JJzPS;e+5ZZmv2Ird&Fv0m
> z@0DlZLa;Z!A>D6nzl>DuE-sDJ)BoU)AMA2^&7P@@*r!@?v7f!{a%#_3!qacMHGKLp
> zp2LNeuJHI5@*Lkmt+U;A2$Y{8^J><7?)dOEu%olIu0w-+AZq?~+UDTf*YNjmceb~B
> z1@9Gq{MNz`mWEHG_C)_hEPn7EsC>Ox`gprzq-7sD^`WeG^qXOn`F3}Ee|c)LxBb@P
> j&?6M@oHUL<cqhZ@rw`i?I-A+!qbGB?<KZ$dW`+L(PyH`>
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev b/tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
> index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..67be268f62afbf2d9459540984da5e9340afdaaa 100644
> GIT binary patch
> literal 364
> zcmebD4+_a)WME)E<>c?|5v<@85#X!<1VAAM5F13Z0I>lOgMkDCNC*yK9F_<M77!bR
> zT_CbNAPOcA5rU8tfYd}Fo(#m3AVP5R|9=P*W*^90CZG_)Tqd06P64W$3dGZacp4BR
> z19WqlN*I`#feJu=QvqVAJ3&HV-~grnLnS<*d<Fpq2Cx%>^a7X|(1HJXfgB(Wb2oz^
> MQ0yI03`oPo01?F*0RR91
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy b/tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
> index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..41981a449fc306b80cccd87ddec3c593a8d72c07 100644
> GIT binary patch
> literal 276
> zcmX|*K@NgI3`M`puy8?wi3^u3IDkhWzycE!jI!Vis5{Ti6^7s1@{>QmeVugXHa@5G
> z0SNbY?1op>&X2C5h#<9Ops%#*0ztdHi8G?q;$EluQNrhn>{ys@`b&R|d8G8O{Jrdl
> mkP$_?rfr{mN!3^;8w}Q?1auX1XIzvDUSRruoXA!(rn3!nx)K2Z
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
> index 2e3e3ccdce..dfb8523c8b 100644
> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> @@ -1,5 +1 @@
> /* List of comma-separated changed AML files to ignore */
> -"tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy",
> -"tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev",
> -"tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy",
> -"tests/data/acpi/aarch64/virt/IORT.smmuv3-dev",
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests
2025-06-27 12:36 ` Eric Auger
@ 2025-06-30 7:11 ` Shameerali Kolothum Thodi via
2025-07-01 6:35 ` Eric Auger
0 siblings, 1 reply; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-06-30 7:11 UTC (permalink / raw)
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, June 27, 2025 1:36 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for
> smmuv3 tests
>
> Hi Shameer,
>
> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> > 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.
>
> You don't describe DSDT at all below, just IORT. I don't know whether it is
> mandated though
I don't think DSDT is required as the code changes we want to test is
IORT related only.
> > ...
> > [030h 0048 1] Type : 00
> > [031h 0049 2] Length : 0018
> > [033h 0051 1] Revision : 01
> > [034h 0052 4] Identifier : 00000000
> > [038h 0056 4] Mapping Count : 00000000
> > [03Ch 0060 4] Mapping Offset : 00000000
> >
> > [040h 0064 4] ItsCount : 00000001
> > [044h 0068 4] Identifiers : 00000000
> >
> > [048h 0072 1] Type : 04
> > [049h 0073 2] Length : 0058
> > [04Bh 0075 1] Revision : 04
> > [04Ch 0076 4] Identifier : 00000001
> > [050h 0080 4] Mapping Count : 00000001
> > [054h 0084 4] Mapping Offset : 00000044
> >
> > [058h 0088 8] Base Address : 0000000009050000
> > [060h 0096 4] Flags (decoded below) : 00000001
> > COHACC Override : 1
> > HTTU Override : 0
> > Proximity Domain Valid : 0
> > [064h 0100 4] Reserved : 00000000
> > [068h 0104 8] VATOS Address : 0000000000000000
> > [070h 0112 4] Model : 00000000
> > [074h 0116 4] Event GSIV : 0000006A
> > [078h 0120 4] PRI GSIV : 0000006B
> > [07Ch 0124 4] GERR GSIV : 0000006D
> > [080h 0128 4] Sync GSIV : 0000006C
> > [084h 0132 4] Proximity Domain : 00000000
> > [088h 0136 4] Device ID Mapping Index : 00000000
> >
> > [08Ch 0140 4] Input base : 00000000
> > [090h 0144 4] ID Count : 0000FFFF
> > [094h 0148 4] Output Base : 00000000
> > [098h 0152 4] Output Reference : 00000030
> > [09Ch 0156 4] Flags (decoded below) : 00000000
> > Single Mapping : 0
> >
> > [0A0h 0160 1] Type : 02
> > [0A1h 0161 2] Length : 0074
> > [0A3h 0163 1] Revision : 03
> > [0A4h 0164 4] Identifier : 00000002
> > [0A8h 0168 4] Mapping Count : 00000004
> > [0ACh 0172 4] Mapping Offset : 00000024
> >
> > [0B0h 0176 8] Memory Properties : [IORT Memory Access
> Properties]
> > [0B0h 0176 4] Cache Coherency : 00000001
> > [0B4h 0180 1] Hints (decoded below) : 00
> > Transient : 0
> > Write Allocate : 0
> > Read Allocate : 0
> > Override : 0
> > [0B5h 0181 2] Reserved : 0000
> > [0B7h 0183 1] Memory Flags (decoded below) : 03
> > Coherency : 1
> > Device Attribute : 1
> > [0B8h 0184 4] ATS Attribute : 00000000
> > [0BCh 0188 4] PCI Segment Number : 00000000
> > [0C0h 0192 1] Memory Size Limit : 40
> > [0C1h 0193 2] PASID Capabilities : 0000
> > [0C3h 0195 1] Reserved : 00
> >
> > [0C4h 0196 4] Input base : 00000000
> > [0C8h 0200 4] ID Count : 000001FF
> > [0CCh 0204 4] Output Base : 00000000
> > [0D0h 0208 4] Output Reference : 00000048
> > [0D4h 0212 4] Flags (decoded below) : 00000000
> > Single Mapping : 0
> >
> > [0D8h 0216 4] Input base : 00001000
> > [0DCh 0220 4] ID Count : 000000FF
> > [0E0h 0224 4] Output Base : 00001000
> > [0E4h 0228 4] Output Reference : 00000048
> > [0E8h 0232 4] Flags (decoded below) : 00000000
> > Single Mapping : 0
> >
> > [0ECh 0236 4] Input base : 00000200
> > [0F0h 0240 4] ID Count : 00000DFF
> > [0F4h 0244 4] Output Base : 00000200
> > [0F8h 0248 4] Output Reference : 00000030
> > [0FCh 0252 4] Flags (decoded below) : 00000000
> > Single Mapping : 0
> >
> > [100h 0256 4] Input base : 00001100
> > [104h 0260 4] ID Count : 0000EEFF
> > [108h 0264 4] Output Base : 00001100
> > [10Ch 0268 4] Output Reference : 00000030
> > [110h 0272 4] Flags (decoded below) : 00000000
> > Single Mapping : 0
> >
> > For the smmuv3-dev test case, IORT has two SMMUV3 nodes and a Root
> > Complex node with ID mappings of which two points to two different
> > SMMUv3 nodes and remianining ones pointing
> remaining. Still difficult to parse for me ;-)
Ok 😊. I will rephrase as suggested in the previous one.
Thanks,
Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests
2025-06-30 7:11 ` Shameerali Kolothum Thodi via
@ 2025-07-01 6:35 ` Eric Auger
0 siblings, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-07-01 6:35 UTC (permalink / raw)
To: Shameerali Kolothum Thodi, qemu-arm@nongnu.org,
qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
On 6/30/25 9:11 AM, Shameerali Kolothum Thodi wrote:
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Friday, June 27, 2025 1:36 PM
>> To: Shameerali Kolothum Thodi
>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>> qemu-devel@nongnu.org
>> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
>> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
>> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
>> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
>> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
>> Jonathan Cameron <jonathan.cameron@huawei.com>;
>> zhangfei.gao@linaro.org
>> Subject: Re: [PATCH v5 11/11] qtest/bios-tables-test: Update tables for
>> smmuv3 tests
>>
>> Hi Shameer,
>>
>> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
>>> 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.
>> You don't describe DSDT at all below, just IORT. I don't know whether it is
>> mandated though
> I don't think DSDT is required as the code changes we want to test is
> IORT related only.
OK. Then I would add in the commit msg the DSDT is not impacted by the
way the SMMU is instantiated.
Thanks
Eric
>
>>> ...
>>> [030h 0048 1] Type : 00
>>> [031h 0049 2] Length : 0018
>>> [033h 0051 1] Revision : 01
>>> [034h 0052 4] Identifier : 00000000
>>> [038h 0056 4] Mapping Count : 00000000
>>> [03Ch 0060 4] Mapping Offset : 00000000
>>>
>>> [040h 0064 4] ItsCount : 00000001
>>> [044h 0068 4] Identifiers : 00000000
>>>
>>> [048h 0072 1] Type : 04
>>> [049h 0073 2] Length : 0058
>>> [04Bh 0075 1] Revision : 04
>>> [04Ch 0076 4] Identifier : 00000001
>>> [050h 0080 4] Mapping Count : 00000001
>>> [054h 0084 4] Mapping Offset : 00000044
>>>
>>> [058h 0088 8] Base Address : 0000000009050000
>>> [060h 0096 4] Flags (decoded below) : 00000001
>>> COHACC Override : 1
>>> HTTU Override : 0
>>> Proximity Domain Valid : 0
>>> [064h 0100 4] Reserved : 00000000
>>> [068h 0104 8] VATOS Address : 0000000000000000
>>> [070h 0112 4] Model : 00000000
>>> [074h 0116 4] Event GSIV : 0000006A
>>> [078h 0120 4] PRI GSIV : 0000006B
>>> [07Ch 0124 4] GERR GSIV : 0000006D
>>> [080h 0128 4] Sync GSIV : 0000006C
>>> [084h 0132 4] Proximity Domain : 00000000
>>> [088h 0136 4] Device ID Mapping Index : 00000000
>>>
>>> [08Ch 0140 4] Input base : 00000000
>>> [090h 0144 4] ID Count : 0000FFFF
>>> [094h 0148 4] Output Base : 00000000
>>> [098h 0152 4] Output Reference : 00000030
>>> [09Ch 0156 4] Flags (decoded below) : 00000000
>>> Single Mapping : 0
>>>
>>> [0A0h 0160 1] Type : 02
>>> [0A1h 0161 2] Length : 0074
>>> [0A3h 0163 1] Revision : 03
>>> [0A4h 0164 4] Identifier : 00000002
>>> [0A8h 0168 4] Mapping Count : 00000004
>>> [0ACh 0172 4] Mapping Offset : 00000024
>>>
>>> [0B0h 0176 8] Memory Properties : [IORT Memory Access
>> Properties]
>>> [0B0h 0176 4] Cache Coherency : 00000001
>>> [0B4h 0180 1] Hints (decoded below) : 00
>>> Transient : 0
>>> Write Allocate : 0
>>> Read Allocate : 0
>>> Override : 0
>>> [0B5h 0181 2] Reserved : 0000
>>> [0B7h 0183 1] Memory Flags (decoded below) : 03
>>> Coherency : 1
>>> Device Attribute : 1
>>> [0B8h 0184 4] ATS Attribute : 00000000
>>> [0BCh 0188 4] PCI Segment Number : 00000000
>>> [0C0h 0192 1] Memory Size Limit : 40
>>> [0C1h 0193 2] PASID Capabilities : 0000
>>> [0C3h 0195 1] Reserved : 00
>>>
>>> [0C4h 0196 4] Input base : 00000000
>>> [0C8h 0200 4] ID Count : 000001FF
>>> [0CCh 0204 4] Output Base : 00000000
>>> [0D0h 0208 4] Output Reference : 00000048
>>> [0D4h 0212 4] Flags (decoded below) : 00000000
>>> Single Mapping : 0
>>>
>>> [0D8h 0216 4] Input base : 00001000
>>> [0DCh 0220 4] ID Count : 000000FF
>>> [0E0h 0224 4] Output Base : 00001000
>>> [0E4h 0228 4] Output Reference : 00000048
>>> [0E8h 0232 4] Flags (decoded below) : 00000000
>>> Single Mapping : 0
>>>
>>> [0ECh 0236 4] Input base : 00000200
>>> [0F0h 0240 4] ID Count : 00000DFF
>>> [0F4h 0244 4] Output Base : 00000200
>>> [0F8h 0248 4] Output Reference : 00000030
>>> [0FCh 0252 4] Flags (decoded below) : 00000000
>>> Single Mapping : 0
>>>
>>> [100h 0256 4] Input base : 00001100
>>> [104h 0260 4] ID Count : 0000EEFF
>>> [108h 0264 4] Output Base : 00001100
>>> [10Ch 0268 4] Output Reference : 00000030
>>> [110h 0272 4] Flags (decoded below) : 00000000
>>> Single Mapping : 0
>>>
>>> For the smmuv3-dev test case, IORT has two SMMUV3 nodes and a Root
>>> Complex node with ID mappings of which two points to two different
>>> SMMUv3 nodes and remianining ones pointing
>> remaining. Still difficult to parse for me ;-)
> Ok 😊. I will rephrase as suggested in the previous one.
>
> Thanks,
> Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (10 preceding siblings ...)
2025-06-23 9:42 ` [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
@ 2025-06-27 12:36 ` Eric Auger
2025-06-30 7:12 ` Shameerali Kolothum Thodi via
2025-07-02 1:01 ` Nathan Chen
12 siblings, 1 reply; 39+ messages in thread
From: Eric Auger @ 2025-06-27 12:36 UTC (permalink / raw)
To: Shameer Kolothum, qemu-arm, qemu-devel
Cc: peter.maydell, jgg, nicolinc, ddutile, berrange, imammedo,
nathanc, mochs, smostafa, gustavo.romero, linuxarm, wangzhou1,
jiangkunkun, jonathan.cameron, zhangfei.gao
Hi Shameer,
On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> Hi All,
>
> Changes from v4:
> https://lore.kernel.org/qemu-devel/20250613144449.60156-1-shameerali.kolothum.thodi@huawei.com/
>
> Major changes from v4:
this will need a respin after merge of
f5ec751ee70d hw/arm/virt: Check bypass iommu is not set for iommu-map
DT property
Thanks
Eric
>
> 1. Added stricter validation for PCI buses associated with the SMMU.
> Only the default PCIe Root Complex (pcie.0) and additional root
> complexes created using pxb-pcie (see patch #1) are allowed.
>
> 2. While testing this series with a setup involving multiple PCIe root
> complexes using pxb-pcie, I encountered an issue related to IOMMU
> ops resolution. Consider the below configuration, where an
> arm-smmuv3 device is associated with the default root complex pcie.0,
> and an additional pxb-pcie-based root complex (pcie.1) is added
> without any associated SMMU:
>
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1 \
> ...
> -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> -device pcie-root-port,id=pcie.port1,chassis=2,bus=pcie.1 \
> -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.2 \
> ...
> -device virtio-net-pci,bus=pcie.0,netdev=net0,id=virtionet.0 \
> -device virtio-net-pci,bus=pcie.port1,netdev=net1,id=virtionet.1
>
> The guest boots fine, and virtionet.0(behind the SMMUV3) bring up
> is successful. However, attempting to bring up virtionet.1
> (behind pcie.1, which lacks a connected SMMU) results in a failure:
>
> root@ubuntu:/# dhclient enp9s0
> arm-smmu-v3 arm-smmu-v3.0.auto: event 0x02 received:
> arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000090000000002
> arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000000000000000
> arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000000000000000
> arm-smmu-v3 arm-smmu-v3.0.auto: 0x0000000000000000
> arm-smmu-v3 arm-smmu-v3.0.auto: event: C_BAD_STREAMID client: (unassigned sid) sid: 0x900 ssid: 0x0
> virtio_net virtio1 enp9s0: NETDEV WATCHDOG: CPU: 2: transmit queue 0 timed out 5172 ms
> virtio_net virtio1 enp9s0: TX timeout on queue: 0, sq: output.0, vq: 0x1, name: output.0, 5172000 usecs ago
> ...
>
> Debug shows that QEMU currently registers IOMMU ops for bus using
> pci_setup_iommu(). However, when retrieving IOMMU ops for a device
> via pci_device_get_iommu_bus_devfn(), the function walks up to the
> parent_dev and fetches the IOMMU ops from the parent, even if the
> current root bus has none configured.
>
> This works today because existing IOMMU models in QEMU are globally
> scoped, and pxb-pcie based extra root complexes can use the
> bypass_iommu property to skip translation as needed.
>
> However, with this series introducing support for associating
> arm-smmuv3 devices with specific PCIe root complexes, this
> becomes problematic. In QEMU, pxb-pcie is implemented as a synthetic
> root complex whose parent_dev is pcie.0. As a result, even though
> pcie.1 has no SMMU attached, pci_device_get_iommu_bus_devfn()
> incorrectly returns the IOMMU ops associated with pcie.0 due to
> the fallback mechanism via parent_dev. This causes devices on
> pcie.1 to erroneously use the address space from pcie.0's SMMU,
> leading to failures like the one above.
>
> To address this, patch #6 in the series introduces a new helper
> function pci_setup_iommu_per_bus(), which explicitly sets the
> iommu_per_bus field in the PCIBus structure. This allows
> pci_device_get_iommu_bus_devfn() to retrieve IOMMU ops based
> on the specific bus.
>
> Not sure this is the correct approach or not. If there is a better
> way to handle this, please let me know .
>
> 3. Picked up few R-by tags where the patch content has not changed much.
>
> 4. Dropped T-by from Nathan for some patches as things have changed a bit.
> @Nathan, apprecaite if you have time to rerun the tests.
>
> 5. Added a bios table tests for both legacy SMMUv3 and new SMMMv3 devices.
> See last few patches.
>
> Cover letter:
>
> This patch series introduces support for a user-creatable SMMUv3 device
> (-device arm-smmuv3) 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) is tied to the machine
> and does not support instantiating multiple SMMUv3 devices—each associated
> with a separate PCIe root complex. In contrast, real-world ARM systems
> often include multiple SMMUv3 instances, each bound to a different PCIe
> root complex.
>
> This series allows to specify multiple SMMUv3 instances as below,
>
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0
> ...
> -device arm-smmuv3,primary-bus=pcie.1,,id=smmuv3.1
>
> The multiple SMMUv3 instance support lays the groundwork for supporting
> accelerated SMMUv3, as proposed in the aforementioned RFCv2[0]. The
> proposed accelerated support will be an optional property like below,
> -device arm-smmuv3,primary-bus=pcie.1,accel=on,..
>
> Please note, the accelerated SMMUv3 support is not part of this series
> and will be sent out as a separate series later on top of this one.
>
> This series also,
>
> -Supports either the legacy iommu=smmuv3 option or the new
> "-device arm-smmuv3" model.
> -Adds device tree bindings for the new SMMUv3 device on the arm/virt
> machine only, and only for the default pcie.0 root complex.
> (Note: pxb-pcie root complexes are currently not supported with the
> device tree due to known limitations[1].)
>
> Example usage:
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0
> -device virtio-net-pci,bus=pcie.0
> -device pxb-pcie,id=pcie.1,bus_nr=2
> -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1
> -device pcie-root-port,id=pcie.port1,bus=pcie.1
> -device virtio-net-pci,bus=pcie.port1
>
> Please take a look and let me know your feedback.
>
> Thanks,
> Shameer
> [0]:https://lore.kernel.org/qemu-devel/20250311141045.66620-1-shameerali.kolothum.thodi@huawei.com/
> [1]:https://lore.kernel.org/qemu-devel/20230421165037.2506-1-Jonathan.Cameron@huawei.com/
>
> Nicolin Chen (1):
> hw/arm/virt: Add an SMMU_IO_LEN macro
>
> Shameer Kolothum (10):
> hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
> hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build
> hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices
> hw/arm/virt: Factor out common SMMUV3 dt bindings code
> hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops
> retrieval
> hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation
> qemu-options.hx: Document the arm-smmuv3 device
> bios-tables-test: Allow for smmuv3 test data.
> qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device
> qtest/bios-tables-test: Update tables for smmuv3 tests
>
> hw/arm/smmu-common.c | 35 +++-
> hw/arm/smmuv3.c | 2 +
> hw/arm/virt-acpi-build.c | 164 ++++++++++++++----
> hw/arm/virt.c | 110 +++++++++---
> hw/core/sysbus-fdt.c | 3 +
> hw/pci-bridge/pci_expander_bridge.c | 1 -
> hw/pci/pci.c | 25 +++
> include/hw/arm/smmu-common.h | 1 +
> include/hw/arm/virt.h | 1 +
> include/hw/pci/pci.h | 2 +
> include/hw/pci/pci_bridge.h | 1 +
> include/hw/pci/pci_bus.h | 1 +
> qemu-options.hx | 7 +
> tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev | Bin 0 -> 10162 bytes
> .../data/acpi/aarch64/virt/DSDT.smmuv3-legacy | Bin 0 -> 10162 bytes
> tests/data/acpi/aarch64/virt/IORT.smmuv3-dev | Bin 0 -> 364 bytes
> .../data/acpi/aarch64/virt/IORT.smmuv3-legacy | Bin 0 -> 276 bytes
> tests/qtest/bios-tables-test.c | 86 +++++++++
> 18 files changed, 375 insertions(+), 64 deletions(-)
> create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-dev
> create mode 100644 tests/data/acpi/aarch64/virt/DSDT.smmuv3-legacy
> create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-dev
> create mode 100644 tests/data/acpi/aarch64/virt/IORT.smmuv3-legacy
>
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device
2025-06-27 12:36 ` [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Eric Auger
@ 2025-06-30 7:12 ` Shameerali Kolothum Thodi via
2025-07-01 6:37 ` Eric Auger
0 siblings, 1 reply; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-06-30 7:12 UTC (permalink / raw)
To: eric.auger@redhat.com, qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, June 27, 2025 1:37 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable
> SMMUv3 device
>
> Hi Shameer,
>
> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
> > Hi All,
> >
> > Changes from v4:
> > https://lore.kernel.org/qemu-devel/20250613144449.60156-1-
> shameerali.kolothum.thodi@huawei.com/
> >
> > Major changes from v4:
> this will need a respin after merge of
> f5ec751ee70d hw/arm/virt: Check bypass iommu is not set for iommu-map
> DT property
Yes. Missed that. Will do.
Thanks,
Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device
2025-06-30 7:12 ` Shameerali Kolothum Thodi via
@ 2025-07-01 6:37 ` Eric Auger
0 siblings, 0 replies; 39+ messages in thread
From: Eric Auger @ 2025-07-01 6:37 UTC (permalink / raw)
To: Shameerali Kolothum Thodi, qemu-arm@nongnu.org,
qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jgg@nvidia.com, nicolinc@nvidia.com,
ddutile@redhat.com, berrange@redhat.com, imammedo@redhat.com,
nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
gustavo.romero@linaro.org, Linuxarm, Wangzhou (B), jiangkunkun,
Jonathan Cameron, zhangfei.gao@linaro.org
On 6/30/25 9:12 AM, Shameerali Kolothum Thodi wrote:
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Friday, June 27, 2025 1:37 PM
>> To: Shameerali Kolothum Thodi
>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>> qemu-devel@nongnu.org
>> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
>> ddutile@redhat.com; berrange@redhat.com; imammedo@redhat.com;
>> nathanc@nvidia.com; mochs@nvidia.com; smostafa@google.com;
>> gustavo.romero@linaro.org; Linuxarm <linuxarm@huawei.com>; Wangzhou
>> (B) <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
>> Jonathan Cameron <jonathan.cameron@huawei.com>;
>> zhangfei.gao@linaro.org
>> Subject: Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable
>> SMMUv3 device
>>
>> Hi Shameer,
>>
>> On 6/23/25 11:42 AM, Shameer Kolothum wrote:
>>> Hi All,
>>>
>>> Changes from v4:
>>> https://lore.kernel.org/qemu-devel/20250613144449.60156-1-
>> shameerali.kolothum.thodi@huawei.com/
>>> Major changes from v4:
>> this will need a respin after merge of
>> f5ec751ee70d hw/arm/virt: Check bypass iommu is not set for iommu-map
>> DT property
you may have seen Gustavo's series
[PATCH-for-10.1 v6 0/9] hw/arm: GIC 'its=off' ACPI table fixes
has been applied to target-arm.next. You shall rebase on top of it and
unfortunately it should conflict with some part of your series
Eric
> Yes. Missed that. Will do.
>
> Thanks,
> Shameer
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device
2025-06-23 9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
` (11 preceding siblings ...)
2025-06-27 12:36 ` [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Eric Auger
@ 2025-07-02 1:01 ` Nathan Chen
2025-07-02 15:08 ` Shameerali Kolothum Thodi via
12 siblings, 1 reply; 39+ messages in thread
From: Nathan Chen @ 2025-07-02 1:01 UTC (permalink / raw)
To: qemu-devel
Cc: berrange, ddutile, eric.auger, gustavo.romero, imammedo, jgg,
jiangkunkun, jonathan.cameron, linuxarm, mochs, nathanc, nicolinc,
peter.maydell, qemu-arm, shameerali.kolothum.thodi, smostafa,
wangzhou1, zhangfei.gao
> To address this, patch #6 in the series introduces a new helper
> function pci_setup_iommu_per_bus(), which explicitly sets the
> iommu_per_bus field in the PCIBus structure. This allows
> pci_device_get_iommu_bus_devfn() to retrieve IOMMU ops based
> on the specific bus.
>
> This patch series introduces support for a user-creatable SMMUv3 device
> (-device arm-smmuv3) in QEMU.
Tested-by: Nathan Chen <nathanc@nvidia.com>
I re-ran the test from v3 [0] and am able to create 16 SMMUv3 devices in
a qemu VM with emulated devices properly associated with the guest SMMUs
in guest sysfs - verified with some guest SMMUs having two or three
emulated NICs assigned to them while other guest SMMUs have a minimum of
one assigned.
Removing SMMUv3 devices from the VM config described above, I do not
observe the problematic behavior where devices behind PXBs without SMMUs
erroneously use the address space from pcie.0's SMMU. I removed SMMUv3
devices from PXBs with one, two, and three emulated NICs assigned to
them. Below are the guest topology and qemu command used where SMMUv3
devices are excluded from the original test:
nvidia@lego-cg1-dvt-59:~$ lspci -tv
-+-[0000:00]-+-00.0 Red Hat, Inc. QEMU PCIe Host bridge
| +-01.0 Red Hat, Inc. QEMU NVM Express Controller
| +-02.0 Intel Corporation 82540EM Gigabit Ethernet Controller
| +-03.0 Red Hat, Inc. Virtio network device
| +-04.0 Red Hat, Inc. Virtio network device
| +-05.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-06.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-07.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-08.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-09.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0a.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0b.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0c.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0d.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0e.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-0f.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-10.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-11.0 Red Hat, Inc. QEMU PCIe Expander bridge
| +-12.0 Red Hat, Inc. QEMU PCIe Expander bridge
| \-13.0 Red Hat, Inc. QEMU PCIe Expander bridge
+-[0000:90]-+-00.0-[91]----00.0 Red Hat, Inc. Virtio 1.0 network device
| \-01.0-[92]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:94]---00.0-[95]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:98]---00.0-[99]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:9c]---00.0-[9d]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:a0]---00.0-[a1]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:a4]---00.0-[a5]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:a8]---00.0-[a9]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:ac]---00.0-[ad]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:b0]---00.0-[b1]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:b4]---00.0-[b5]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:b8]---00.0-[b9]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:bc]---00.0-[bd]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:c0]---00.0-[c1]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-[0000:c4]---00.0-[c5]----00.0 Red Hat, Inc. Virtio 1.0 network device
\-[0000:c8]-+-00.0-[c9]----00.0 Red Hat, Inc. Virtio 1.0 network device
+-01.0-[ca]----00.0 Red Hat, Inc. Virtio 1.0 network device
\-02.0-[cb]----00.0 Red Hat, Inc. Virtio 1.0 network device
qemu-system-aarch64 \
-machine hmat=on -machine virt,accel=kvm,gic-version=3,ras=on \
-cpu host -smp cpus=4 -m size=16G,slots=4,maxmem=32G -nographic \
-bios /usr/share/AAVMF/AAVMF_CODE.fd \
-device nvme,drive=nvme0,serial=deadbeaf1,bus=pcie.0 \
-drive
file=/localhome/local-nathanc/noble-server-cloudimg-arm64.qcow2,index=0,media=disk,format=qcow2,if=none,id=nvme0
\
-device
e1000,romfile=/localhome/local-nathanc/efi-e1000.rom,netdev=net0,bus=pcie.0
\
-netdev
user,id=net0,hostfwd=tcp::5558-:22,hostfwd=tcp::5586-:5586 \
-netdev user,id=net1 \
-netdev user,id=net2 \
-netdev user,id=net3 \
-netdev user,id=net4 \
-netdev user,id=net5 \
-netdev user,id=net6 \
-netdev user,id=net7 \
-netdev user,id=net8 \
-netdev user,id=net9 \
-netdev user,id=net10 \
-netdev user,id=net11 \
-netdev user,id=net12 \
-netdev user,id=net13 \
-netdev user,id=net14 \
-netdev user,id=net15 \
-netdev user,id=net16 \
-netdev user,id=net17 \
-netdev user,id=net18 \
-netdev user,id=net19 \
-netdev user,id=net20 \
-device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
-device virtio-net-pci,bus=pcie.0,netdev=net1 \
-device virtio-net-pci,bus=pcie.0,netdev=net20 \
-device pxb-pcie,id=pcie.1,bus_nr=200,bus=pcie.0 \
-device pcie-root-port,id=pcie.port1,bus=pcie.1,slot=1,chassis=1 \
-device virtio-net-pci,bus=pcie.port1,netdev=net2 \
-device
pcie-root-port,id=pcie.port17,bus=pcie.1,slot=17,chassis=17 \
-device virtio-net-pci,bus=pcie.port17,netdev=net18 \
-device
pcie-root-port,id=pcie.port18,bus=pcie.1,slot=18,chassis=18 \
-device virtio-net-pci,bus=pcie.port18,netdev=net19 \
-device pxb-pcie,id=pcie.2,bus_nr=196,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.2,id=smmuv3.2 \
-device pcie-root-port,id=pcie.port2,bus=pcie.2,slot=2,chassis=2 \
-device virtio-net-pci,bus=pcie.port2,netdev=net3 \
-device pxb-pcie,id=pcie.3,bus_nr=192,bus=pcie.0 \
-device pcie-root-port,id=pcie.port3,bus=pcie.3,slot=3,chassis=3 \
-device virtio-net-pci,bus=pcie.port3,netdev=net4 \
-device pxb-pcie,id=pcie.4,bus_nr=188,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.4,id=smmuv3.4 \
-device pcie-root-port,id=pcie.port4,bus=pcie.4,slot=4,chassis=4 \
-device virtio-net-pci,bus=pcie.port4,netdev=net5 \
-device pxb-pcie,id=pcie.5,bus_nr=184,bus=pcie.0 \
-device pcie-root-port,id=pcie.port5,bus=pcie.5,slot=5,chassis=5 \
-device virtio-net-pci,bus=pcie.port5,netdev=net6 \
-device pxb-pcie,id=pcie.6,bus_nr=180,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.6,id=smmuv3.6 \
-device pcie-root-port,id=pcie.port6,bus=pcie.6,slot=6,chassis=6 \
-device virtio-net-pci,bus=pcie.port6,netdev=net7 \
-device pxb-pcie,id=pcie.7,bus_nr=176,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.7,id=smmuv3.7 \
-device pcie-root-port,id=pcie.port7,bus=pcie.7,slot=7,chassis=7 \
-device virtio-net-pci,bus=pcie.port7,netdev=net8 \
-device pxb-pcie,id=pcie.8,bus_nr=172,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.8,id=smmuv3.8 \
-device pcie-root-port,id=pcie.port8,bus=pcie.8,slot=8,chassis=8 \
-device virtio-net-pci,bus=pcie.port8,netdev=net9 \
-device pxb-pcie,id=pcie.9,bus_nr=168,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.9,id=smmuv3.9 \
-device pcie-root-port,id=pcie.port9,bus=pcie.9,slot=9,chassis=9 \
-device virtio-net-pci,bus=pcie.port9,netdev=net10 \
-device pxb-pcie,id=pcie.10,bus_nr=164,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.10,id=smmuv3.10 \
-device
pcie-root-port,id=pcie.port10,bus=pcie.10,slot=10,chassis=10 \
-device virtio-net-pci,bus=pcie.port10,netdev=net11 \
-device pxb-pcie,id=pcie.11,bus_nr=160,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.11,id=smmuv3.11 \
-device
pcie-root-port,id=pcie.port11,bus=pcie.11,slot=11,chassis=11 \
-device virtio-net-pci,bus=pcie.port11,netdev=net12 \
-device pxb-pcie,id=pcie.12,bus_nr=156,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.12,id=smmuv3.12 \
-device
pcie-root-port,id=pcie.port12,bus=pcie.12,slot=12,chassis=12 \
-device virtio-net-pci,bus=pcie.port12,netdev=net13 \
-device pxb-pcie,id=pcie.13,bus_nr=152,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.13,id=smmuv3.13 \
-device
pcie-root-port,id=pcie.port13,bus=pcie.13,slot=13,chassis=13 \
-device virtio-net-pci,bus=pcie.port13,netdev=net14 \
-device pxb-pcie,id=pcie.14,bus_nr=148,bus=pcie.0 \
-device arm-smmuv3,primary-bus=pcie.14,id=smmuv3.14 \
-device
pcie-root-port,id=pcie.port14,bus=pcie.14,slot=14,chassis=14 \
-device virtio-net-pci,bus=pcie.port14,netdev=net15 \
-device pxb-pcie,id=pcie.15,bus_nr=144,bus=pcie.0 \
-device
pcie-root-port,id=pcie.port15,bus=pcie.15,slot=15,chassis=15 \
-device virtio-net-pci,bus=pcie.port15,netdev=net16 \
-device
pcie-root-port,id=pcie.port16,bus=pcie.15,slot=16,chassis=16 \
-device virtio-net-pci,bus=pcie.port16,netdev=net17
[0]
https://lore.kernel.org/all/90957693-dc12-4731-960f-0ee295d297ec@nvidia.com/
Thanks,
Nathan
^ permalink raw reply [flat|nested] 39+ messages in thread* RE: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device
2025-07-02 1:01 ` Nathan Chen
@ 2025-07-02 15:08 ` Shameerali Kolothum Thodi via
0 siblings, 0 replies; 39+ messages in thread
From: Shameerali Kolothum Thodi via @ 2025-07-02 15:08 UTC (permalink / raw)
To: Nathan Chen, qemu-devel@nongnu.org
Cc: berrange@redhat.com, ddutile@redhat.com, eric.auger@redhat.com,
gustavo.romero@linaro.org, imammedo@redhat.com, jgg@nvidia.com,
jiangkunkun, Jonathan Cameron, Linuxarm, mochs@nvidia.com,
nicolinc@nvidia.com, peter.maydell@linaro.org,
qemu-arm@nongnu.org, smostafa@google.com, Wangzhou (B),
zhangfei.gao@linaro.org
> -----Original Message-----
> From: Nathan Chen <nathanc@nvidia.com>
> Sent: Wednesday, July 2, 2025 2:02 AM
> To: qemu-devel@nongnu.org
> Cc: berrange@redhat.com; ddutile@redhat.com; eric.auger@redhat.com;
> gustavo.romero@linaro.org; imammedo@redhat.com; jgg@nvidia.com;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; Linuxarm <linuxarm@huawei.com>;
> mochs@nvidia.com; nathanc@nvidia.com; nicolinc@nvidia.com;
> peter.maydell@linaro.org; qemu-arm@nongnu.org; Shameerali Kolothum
> Thodi <shameerali.kolothum.thodi@huawei.com>; smostafa@google.com;
> Wangzhou (B) <wangzhou1@hisilicon.com>; zhangfei.gao@linaro.org
> Subject: Re: [PATCH v5 00/11] hw/arm/virt: Add support for user creatable
> SMMUv3 device
>
> > To address this, patch #6 in the series introduces a new helper
> > function pci_setup_iommu_per_bus(), which explicitly sets the
> > iommu_per_bus field in the PCIBus structure. This allows
> > pci_device_get_iommu_bus_devfn() to retrieve IOMMU ops based
> > on the specific bus.
> >
> > This patch series introduces support for a user-creatable SMMUv3
> device
> > (-device arm-smmuv3) in QEMU.
>
> Tested-by: Nathan Chen <nathanc@nvidia.com>
>
> I re-ran the test from v3 [0] and am able to create 16 SMMUv3 devices in
> a qemu VM with emulated devices properly associated with the guest
> SMMUs
> in guest sysfs - verified with some guest SMMUs having two or three
> emulated NICs assigned to them while other guest SMMUs have a minimum
> of
> one assigned.
>
> Removing SMMUv3 devices from the VM config described above, I do not
> observe the problematic behavior where devices behind PXBs without
> SMMUs
> erroneously use the address space from pcie.0's SMMU. I removed SMMUv3
> devices from PXBs with one, two, and three emulated NICs assigned to
> them. Below are the guest topology and qemu command used where
> SMMUv3
> devices are excluded from the original test:
Cool. Appreciate testing that specifically.
Thanks,
Shameer
^ permalink raw reply [flat|nested] 39+ messages in thread