QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
be useful to report ATS capability to the guest so it can take advantage
of it if the device also supports ATS.

Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
registers alone, as firmware ACPI IORT tables may override them. The
user must therefore ensure the support before enabling it.

Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
 hw/arm/smmuv3-accel.c    |  4 ++++
 hw/arm/smmuv3.c          | 25 ++++++++++++++++++++++++-
 hw/arm/virt-acpi-build.c | 10 ++++++++--
 include/hw/arm/smmuv3.h  |  1 +
 4 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
index e8607b253e..eee54316bf 100644
--- a/hw/arm/smmuv3-accel.c
+++ b/hw/arm/smmuv3-accel.c
@@ -644,6 +644,10 @@ void smmuv3_accel_idr_override(SMMUv3State *s)
     if (!s->ril) {
         s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 0);
     }
+    /* QEMU SMMUv3 has no ATS. Update IDR0 if user has enabled it */
+    if (s->ats) {
+        s->idr[0] = FIELD_DP32(s->idr[0], IDR0, ATS, 1); /* ATS */
+    }
 }
 
 /*
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 0f3a61646a..77d46a9cd6 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -1510,13 +1510,28 @@ static int smmuv3_cmdq_consume(SMMUv3State *s)
              */
             smmuv3_range_inval(bs, &cmd, SMMU_STAGE_2);
             break;
+        case SMMU_CMD_ATC_INV:
+        {
+            SMMUDevice *sdev = smmu_find_sdev(bs, CMD_SID(&cmd));
+            Error *local_err = NULL;
+
+            if (!sdev) {
+                break;
+            }
+
+            if (!smmuv3_accel_issue_inv_cmd(s, &cmd, sdev, &local_err)) {
+                error_report_err(local_err);
+                cmd_error = SMMU_CERROR_ILL;
+                break;
+            }
+            break;
+        }
         case SMMU_CMD_TLBI_EL3_ALL:
         case SMMU_CMD_TLBI_EL3_VA:
         case SMMU_CMD_TLBI_EL2_ALL:
         case SMMU_CMD_TLBI_EL2_ASID:
         case SMMU_CMD_TLBI_EL2_VA:
         case SMMU_CMD_TLBI_EL2_VAA:
-        case SMMU_CMD_ATC_INV:
         case SMMU_CMD_PRI_RESP:
         case SMMU_CMD_RESUME:
         case SMMU_CMD_STALL_TERM:
@@ -1934,6 +1949,10 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
         error_setg(errp, "ril can only be disabled if accel=on");
         return false;
     }
+    if (s->ats) {
+        error_setg(errp, "ats can only be enabled if accel=on");
+        return false;
+    }
     return true;
 }
 
@@ -2058,6 +2077,7 @@ static const Property smmuv3_properties[] = {
     DEFINE_PROP_BOOL("accel", SMMUv3State, accel, false),
     /* RIL can be turned off for accel cases */
     DEFINE_PROP_BOOL("ril", SMMUv3State, ril, true),
+    DEFINE_PROP_BOOL("ats", SMMUv3State, ats, false),
 };
 
 static void smmuv3_instance_init(Object *obj)
@@ -2087,6 +2107,9 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
                                           "in nested mode for vfio-pci dev assignment");
     object_class_property_set_description(klass, "ril",
         "Enable/disable range invalidation support");
+    object_class_property_set_description(klass, "ats",
+        "Enable/disable ATS support. Please ensure host platform has ATS "
+        "support before enabling this");
 }
 
 static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index d0c1e10019..a53f0229b8 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -322,6 +322,7 @@ typedef struct AcpiIortSMMUv3Dev {
     /* Offset of the SMMUv3 IORT Node relative to the start of the IORT */
     size_t offset;
     bool accel;
+    bool ats;
 } AcpiIortSMMUv3Dev;
 
 /*
@@ -377,6 +378,7 @@ static int iort_smmuv3_devices(Object *obj, void *opaque)
 
     bus = PCI_BUS(object_property_get_link(obj, "primary-bus", &error_abort));
     sdev.accel = object_property_get_bool(obj, "accel", &error_abort);
+    sdev.ats = object_property_get_bool(obj, "ats", &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);
@@ -511,6 +513,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
     int i, nb_nodes, rc_mapping_count;
     AcpiIortSMMUv3Dev *sdev;
     size_t node_size;
+    bool ats_needed = false;
     int num_smmus = 0;
     uint32_t id = 0;
     int rc_smmu_idmaps_len = 0;
@@ -546,6 +549,9 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
         /* Calculate RMR nodes required. One per SMMUv3 with accelerated mode */
         for (i = 0; i < num_smmus; i++) {
             sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
+            if (sdev->ats) {
+                ats_needed = true;
+            }
             if (sdev->accel) {
                 nb_nodes++;
             }
@@ -645,8 +651,8 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
     build_append_int_noprefix(table_data, 0, 2); /* Reserved */
     /* Table 15 Memory Access Flags */
     build_append_int_noprefix(table_data, 0x3 /* CCA = CPM = DACS = 1 */, 1);
-
-    build_append_int_noprefix(table_data, 0, 4); /* ATS Attribute */
+    /* ATS Attribute */
+    build_append_int_noprefix(table_data, (ats_needed ? 1 : 0), 4);
     /* MCFG pci_segment */
     build_append_int_noprefix(table_data, 0, 4); /* PCI Segment number */
 
diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
index c555ea684e..6f07baa144 100644
--- a/include/hw/arm/smmuv3.h
+++ b/include/hw/arm/smmuv3.h
@@ -69,6 +69,7 @@ struct SMMUv3State {
     struct SMMUv3AccelState  *s_accel;
     Error  *migration_blocker;
     bool ril;
+    bool ats;
 };
 
 typedef enum {
-- 
2.43.0

Hi Shameer,
On 9/29/25 3:36 PM, Shameer Kolothum wrote:
> QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
> When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
> be useful to report ATS capability to the guest so it can take advantage
> of it if the device also supports ATS.
>
> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> registers alone, as firmware ACPI IORT tables may override them. The
> user must therefore ensure the support before enabling it.
This looks incomplete to me. ATS is a big topic in itself. I would
prefer we do not advertise it until we do not have full support for it
(including emulation). Comparing to
c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
contributed we miss at least translation request implementations
(PCIIOMMUOps ats_request_translation callback implementation).

See:
https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu--drif@eviden.com/#r

Also in SMMU spec I see other stuff like STE.EATS, ATS skipping stage 1,
... Here I only see  SMMU_CMD_ATC_INV and this is only implemented for
accel. I think I would rather stick to the minimum in this series, ie.
reject in case of ATS mismatch (for testing purpose you will just need a
small hack until we get ATS support), work on ATS enablement in parallel
. Thanks Eric
>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  hw/arm/smmuv3-accel.c    |  4 ++++
>  hw/arm/smmuv3.c          | 25 ++++++++++++++++++++++++-
>  hw/arm/virt-acpi-build.c | 10 ++++++++--
>  include/hw/arm/smmuv3.h  |  1 +
>  4 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
> index e8607b253e..eee54316bf 100644
> --- a/hw/arm/smmuv3-accel.c
> +++ b/hw/arm/smmuv3-accel.c
> @@ -644,6 +644,10 @@ void smmuv3_accel_idr_override(SMMUv3State *s)
>      if (!s->ril) {
>          s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 0);
>      }
> +    /* QEMU SMMUv3 has no ATS. Update IDR0 if user has enabled it */
> +    if (s->ats) {
> +        s->idr[0] = FIELD_DP32(s->idr[0], IDR0, ATS, 1); /* ATS */
> +    }
>  }
>  
>  /*
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 0f3a61646a..77d46a9cd6 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -1510,13 +1510,28 @@ static int smmuv3_cmdq_consume(SMMUv3State *s)
>               */
>              smmuv3_range_inval(bs, &cmd, SMMU_STAGE_2);
>              break;
> +        case SMMU_CMD_ATC_INV:
> +        {
> +            SMMUDevice *sdev = smmu_find_sdev(bs, CMD_SID(&cmd));
> +            Error *local_err = NULL;
> +
> +            if (!sdev) {
> +                break;
> +            }
> +
> +            if (!smmuv3_accel_issue_inv_cmd(s, &cmd, sdev, &local_err)) {
> +                error_report_err(local_err);
> +                cmd_error = SMMU_CERROR_ILL;
> +                break;
> +            }
> +            break;
> +        }
>          case SMMU_CMD_TLBI_EL3_ALL:
>          case SMMU_CMD_TLBI_EL3_VA:
>          case SMMU_CMD_TLBI_EL2_ALL:
>          case SMMU_CMD_TLBI_EL2_ASID:
>          case SMMU_CMD_TLBI_EL2_VA:
>          case SMMU_CMD_TLBI_EL2_VAA:
> -        case SMMU_CMD_ATC_INV:
>          case SMMU_CMD_PRI_RESP:
>          case SMMU_CMD_RESUME:
>          case SMMU_CMD_STALL_TERM:
> @@ -1934,6 +1949,10 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
>          error_setg(errp, "ril can only be disabled if accel=on");
>          return false;
>      }
> +    if (s->ats) {
> +        error_setg(errp, "ats can only be enabled if accel=on");
> +        return false;
> +    }
>      return true;
>  }
>  
> @@ -2058,6 +2077,7 @@ static const Property smmuv3_properties[] = {
>      DEFINE_PROP_BOOL("accel", SMMUv3State, accel, false),
>      /* RIL can be turned off for accel cases */
>      DEFINE_PROP_BOOL("ril", SMMUv3State, ril, true),
> +    DEFINE_PROP_BOOL("ats", SMMUv3State, ats, false),
>  };
>  
>  static void smmuv3_instance_init(Object *obj)
> @@ -2087,6 +2107,9 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
>                                            "in nested mode for vfio-pci dev assignment");
>      object_class_property_set_description(klass, "ril",
>          "Enable/disable range invalidation support");
> +    object_class_property_set_description(klass, "ats",
> +        "Enable/disable ATS support. Please ensure host platform has ATS "
> +        "support before enabling this");
>  }
>  
>  static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index d0c1e10019..a53f0229b8 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -322,6 +322,7 @@ typedef struct AcpiIortSMMUv3Dev {
>      /* Offset of the SMMUv3 IORT Node relative to the start of the IORT */
>      size_t offset;
>      bool accel;
> +    bool ats;
>  } AcpiIortSMMUv3Dev;
>  
>  /*
> @@ -377,6 +378,7 @@ static int iort_smmuv3_devices(Object *obj, void *opaque)
>  
>      bus = PCI_BUS(object_property_get_link(obj, "primary-bus", &error_abort));
>      sdev.accel = object_property_get_bool(obj, "accel", &error_abort);
> +    sdev.ats = object_property_get_bool(obj, "ats", &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);
> @@ -511,6 +513,7 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>      int i, nb_nodes, rc_mapping_count;
>      AcpiIortSMMUv3Dev *sdev;
>      size_t node_size;
> +    bool ats_needed = false;
>      int num_smmus = 0;
>      uint32_t id = 0;
>      int rc_smmu_idmaps_len = 0;
> @@ -546,6 +549,9 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>          /* Calculate RMR nodes required. One per SMMUv3 with accelerated mode */
>          for (i = 0; i < num_smmus; i++) {
>              sdev = &g_array_index(smmuv3_devs, AcpiIortSMMUv3Dev, i);
> +            if (sdev->ats) {
> +                ats_needed = true;
> +            }
>              if (sdev->accel) {
>                  nb_nodes++;
>              }
> @@ -645,8 +651,8 @@ build_iort(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>      build_append_int_noprefix(table_data, 0, 2); /* Reserved */
>      /* Table 15 Memory Access Flags */
>      build_append_int_noprefix(table_data, 0x3 /* CCA = CPM = DACS = 1 */, 1);
> -
> -    build_append_int_noprefix(table_data, 0, 4); /* ATS Attribute */
> +    /* ATS Attribute */
> +    build_append_int_noprefix(table_data, (ats_needed ? 1 : 0), 4);
>      /* MCFG pci_segment */
>      build_append_int_noprefix(table_data, 0, 4); /* PCI Segment number */
>  
> diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
> index c555ea684e..6f07baa144 100644
> --- a/include/hw/arm/smmuv3.h
> +++ b/include/hw/arm/smmuv3.h
> @@ -69,6 +69,7 @@ struct SMMUv3State {
>      struct SMMUv3AccelState  *s_accel;
>      Error  *migration_blocker;
>      bool ril;
> +    bool ats;
>  };
>  
>  typedef enum {

Hi Eric,

> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: 27 October 2025 16:59
> To: Shameer Kolothum <skolothumtho@nvidia.com>; qemu-
> arm@nongnu.org; qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; Jason Gunthorpe <jgg@nvidia.com>; Nicolin
> Chen <nicolinc@nvidia.com>; ddutile@redhat.com; berrange@redhat.com;
> Nathan Chen <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>;
> smostafa@google.com; wangzhou1@hisilicon.com;
> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
> shameerkolothum@gmail.com
> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Shameer,
> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
> > QEMU SMMUv3 does not enable ATS (Address Translation Services) by
> default.
> > When accelerated mode is enabled and the host SMMUv3 supports ATS, it
> can
> > be useful to report ATS capability to the guest so it can take advantage
> > of it if the device also supports ATS.
> >
> > Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> > registers alone, as firmware ACPI IORT tables may override them. The
> > user must therefore ensure the support before enabling it.
> This looks incomplete to me. ATS is a big topic in itself. I would
> prefer we do not advertise it until we do not have full support for it
> (including emulation). Comparing to
> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
> contributed we miss at least translation request implementations
> (PCIIOMMUOps ats_request_translation callback implementation).

I may be wrong, but from a quick look, these ats_request_translation() only
matters for emulated devices, right? For pass-through devices, the translation
happens at hardware level IIUC.

Not sure, your concern is compatibility with emulation support or 
breaking any functionality here.

> 
> See:
> https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu--
> drif@eviden.com/#r
> 
> Also in SMMU spec I see other stuff like STE.EATS, ATS skipping stage 1,
> ... Here I only see  SMMU_CMD_ATC_INV and this is only implemented for
> accel. I think I would rather stick to the minimum in this series, ie.
> reject in case of ATS mismatch (for testing purpose you will just need a
> small hack until we get ATS support), work on ATS enablement in parallel

I think that is taken care in kernel.
See arm_smmu_validate_vste() in arm-smmu-v3-iommufd.c

I will double check that though.

Thanks,
Shameer

Hi Eric,

On Mon, Oct 27, 2025 at 05:59:13PM +0100, Eric Auger wrote:
> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
> > QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
> > When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
> > be useful to report ATS capability to the guest so it can take advantage
> > of it if the device also supports ATS.
> >
> > Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> > registers alone, as firmware ACPI IORT tables may override them. The
> > user must therefore ensure the support before enabling it.

> This looks incomplete to me. ATS is a big topic in itself. I would
> prefer we do not advertise it until we do not have full support for it
> (including emulation). Comparing to
> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
> contributed we miss at least translation request implementations
> (PCIIOMMUOps ats_request_translation callback implementation).
> 
> See:
> https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu--drif@eviden.com/#r

In accelerated SMMUv3 case, ATS translation and invalidation are
done by the physical SMMU. Wondering why do we need this?

IIRC, intel is mixing their emulated translation and accelerated
one, and their pasid table is not integrated like SMMU's CD table
that we already passed entirely via the STE.

> Also in SMMU spec I see other stuff like STE.EATS, ATS skipping stage 1,
> ... Here I only see  SMMU_CMD_ATC_INV and this is only implemented for
> accel. I think I would rather stick to the minimum in this series, ie.
> reject in case of ATS mismatch (for testing purpose you will just need a
> small hack until we get ATS support), work on ATS enablement in parallel

That SMMU_CMD_ATC_INV seems to be the only thing we need for ATS..

Thanks
Nicolin

On 10/27/25 6:13 PM, Nicolin Chen wrote:
> Hi Eric,
>
> On Mon, Oct 27, 2025 at 05:59:13PM +0100, Eric Auger wrote:
>> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
>>> QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
>>> When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
>>> be useful to report ATS capability to the guest so it can take advantage
>>> of it if the device also supports ATS.
>>>
>>> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
>>> registers alone, as firmware ACPI IORT tables may override them. The
>>> user must therefore ensure the support before enabling it.
>> This looks incomplete to me. ATS is a big topic in itself. I would
>> prefer we do not advertise it until we do not have full support for it
>> (including emulation). Comparing to
>> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
>> contributed we miss at least translation request implementations
>> (PCIIOMMUOps ats_request_translation callback implementation).
>>
>> See:
>> https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu--drif@eviden.com/#r
> In accelerated SMMUv3 case, ATS translation and invalidation are
> done by the physical SMMU. Wondering why do we need this?

in 06/27 you still can have emulated EPs hotplugged in the loop, no?

I remember some discussions with Peter who was also reluctant in general
to introduce some partial feature support. I think in general this is a
good policy to have features emulated and then accelerated. That's also
good for testing in case we can bring up some test env.

Thanks

Eric
>
> IIRC, intel is mixing their emulated translation and accelerated
> one, and their pasid table is not integrated like SMMU's CD table
> that we already passed entirely via the STE.
>
>> Also in SMMU spec I see other stuff like STE.EATS, ATS skipping stage 1,
>> ... Here I only see  SMMU_CMD_ATC_INV and this is only implemented for
>> accel. I think I would rather stick to the minimum in this series, ie.
>> reject in case of ATS mismatch (for testing purpose you will just need a
>> small hack until we get ATS support), work on ATS enablement in parallel
> That SMMU_CMD_ATC_INV seems to be the only thing we need for ATS..
>
> Thanks
> Nicolin
>

On Mon, Oct 27, 2025 at 06:38:08PM +0100, Eric Auger wrote:
> 
> 
> On 10/27/25 6:13 PM, Nicolin Chen wrote:
> > Hi Eric,
> >
> > On Mon, Oct 27, 2025 at 05:59:13PM +0100, Eric Auger wrote:
> >> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
> >>> QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
> >>> When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
> >>> be useful to report ATS capability to the guest so it can take advantage
> >>> of it if the device also supports ATS.
> >>>
> >>> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> >>> registers alone, as firmware ACPI IORT tables may override them. The
> >>> user must therefore ensure the support before enabling it.
> >> This looks incomplete to me. ATS is a big topic in itself. I would
> >> prefer we do not advertise it until we do not have full support for it
> >> (including emulation). Comparing to
> >> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
> >> contributed we miss at least translation request implementations
> >> (PCIIOMMUOps ats_request_translation callback implementation).
> >>
> >> See:
> >> https://lore.kernel.org/all/20250628180226.133285-11-clement.mathieu--drif@eviden.com/#r
> > In accelerated SMMUv3 case, ATS translation and invalidation are
> > done by the physical SMMU. Wondering why do we need this?
> 
> in 06/27 you still can have emulated EPs hotplugged in the loop, no?
> 
> I remember some discussions with Peter who was also reluctant in general
> to introduce some partial feature support. I think in general this is a
> good policy to have features emulated and then accelerated. That's also
> good for testing in case we can bring up some test env.

Hmm, that sounds a legit reason, though adding the ATS support to
the emulated SMMUv3 isn't seemingly a small effort...

Also, do we have any emulated EP to test out ATS translation and
invalidation from the emulated SMMUv3?

Thanks
Nicolin

On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:

> Hmm, that sounds a legit reason, though adding the ATS support to
> the emulated SMMUv3 isn't seemingly a small effort...

What is "emulated ATS" anyhow?

Jason

On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
>
>> Hmm, that sounds a legit reason, though adding the ATS support to
>> the emulated SMMUv3 isn't seemingly a small effort...
> What is "emulated ATS" anyhow?
I guess it means implementing ATS translation requests and capability to
send ATS invalidations. something like:

https://lore.kernel.org/all/20250628180226.133285-1-clement.mathieu--drif@eviden.com/

Eric

>
> Jason
>

On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
> 
> 
> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
> > On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
> >
> >> Hmm, that sounds a legit reason, though adding the ATS support to
> >> the emulated SMMUv3 isn't seemingly a small effort...
> > What is "emulated ATS" anyhow?
> I guess it means implementing ATS translation requests and capability to
> send ATS invalidations. something like:
> 
> https://lore.kernel.org/all/20250628180226.133285-1-clement.mathieu--drif@eviden.com/

Why would you even want this? The cover letter didn't explain what the
point was.

qemu emulating two levels of IOTLB caching in software, with a
software page table walk?? Why??

Jason

On 10/28/25 2:41 PM, Jason Gunthorpe wrote:
> On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
>>
>> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
>>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
>>>
>>>> Hmm, that sounds a legit reason, though adding the ATS support to
>>>> the emulated SMMUv3 isn't seemingly a small effort...
>>> What is "emulated ATS" anyhow?
>> I guess it means implementing ATS translation requests and capability to
>> send ATS invalidations. something like:
>>
>> https://lore.kernel.org/all/20250628180226.133285-1-clement.mathieu--drif@eviden.com/
> Why would you even want this? The cover letter didn't explain what the
> point was.

well I am just concerned about exposing ATS support to emulated EPs
while we actually do not support it.
>
> qemu emulating two levels of IOTLB caching in software, with a
> software page table walk?? Why??
About the actual use case for ATS emulation you'd rather ask the
contributor, early SW development, IP development?

Eric
>
> Jason
>

On Tue, Oct 28, 2025 at 02:51:29PM +0100, Eric Auger wrote:
> 
> 
> On 10/28/25 2:41 PM, Jason Gunthorpe wrote:
> > On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
> >>
> >> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
> >>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
> >>>
> >>>> Hmm, that sounds a legit reason, though adding the ATS support to
> >>>> the emulated SMMUv3 isn't seemingly a small effort...
> >>> What is "emulated ATS" anyhow?
> >> I guess it means implementing ATS translation requests and capability to
> >> send ATS invalidations. something like:
> >>
> >> https://lore.kernel.org/all/20250628180226.133285-1-clement.mathieu--drif@eviden.com/
> > Why would you even want this? The cover letter didn't explain what the
> > point was.
> 
> well I am just concerned about exposing ATS support to emulated EPs
> while we actually do not support it.

Sure, that shouldn't be done. There is ACPI/DT tables indicating if the
each device supports ATS and qemu should not be marking the emulated
EPs as ATS capable in the first place..

However, there is no big work with showing EPs as ATS capable. They
don't implement an ATC and there is no concept of "translated address"
inside qemu so the only requirement to make it "work" is to just NOP
the ATC invalidation SMMU commands for those EPs.

> > qemu emulating two levels of IOTLB caching in software, with a
> > software page table walk?? Why??
> About the actual use case for ATS emulation you'd rather ask the
> contributor, early SW development, IP development?

I guess, I assume some OOT driver is trying to model their ATC with
more accuracy. Maybe to bolt qemu onto a chip emulator.

Jason

On 10/28/25 3:03 PM, Jason Gunthorpe wrote:
> On Tue, Oct 28, 2025 at 02:51:29PM +0100, Eric Auger wrote:
>>
>> On 10/28/25 2:41 PM, Jason Gunthorpe wrote:
>>> On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
>>>> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
>>>>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
>>>>>
>>>>>> Hmm, that sounds a legit reason, though adding the ATS support to
>>>>>> the emulated SMMUv3 isn't seemingly a small effort...
>>>>> What is "emulated ATS" anyhow?
>>>> I guess it means implementing ATS translation requests and capability to
>>>> send ATS invalidations. something like:
>>>>
>>>> https://lore.kernel.org/all/20250628180226.133285-1-clement.mathieu--drif@eviden.com/
>>> Why would you even want this? The cover letter didn't explain what the
>>> point was.
>> well I am just concerned about exposing ATS support to emulated EPs
>> while we actually do not support it.
> Sure, that shouldn't be done. There is ACPI/DT tables indicating if the
> each device supports ATS and qemu should not be marking the emulated
> EPs as ATS capable in the first place..
>
> However, there is no big work with showing EPs as ATS capable. They
> don't implement an ATC and there is no concept of "translated address"
> inside qemu so the only requirement to make it "work" is to just NOP
> the ATC invalidation SMMU commands for those EPs.
For the record, there is some form of ATS support in virtio-pci devices.
They have an ats property. See hw/virtio/virtio-pci.c and
virtio_pci_ats_ctrl_trigger/pcie_ats_config_write

vhost can be seen as implementing an ATC cache on kernel side.

https://lore.kernel.org/all/20230512135122.70403-1-viktor@daynix.com/
>
>>> qemu emulating two levels of IOTLB caching in software, with a
>>> software page table walk?? Why??
>> About the actual use case for ATS emulation you'd rather ask the
>> contributor, early SW development, IP development?
> I guess, I assume some OOT driver is trying to model their ATC with
> more accuracy. Maybe to bolt qemu onto a chip emulator.
>
> Jason
>

On Tue, Oct 28, 2025 at 03:59:02PM +0100, Eric Auger wrote:
> For the record, there is some form of ATS support in virtio-pci devices.
> They have an ats property. See hw/virtio/virtio-pci.c and
> virtio_pci_ats_ctrl_trigger/pcie_ats_config_write

That seems overkill to me :(

It is fine to cache some of the IOTLB in the kernel, just drive the
kernel invalidations against the main IOTLB instead of muddling ATS
into this.

Jason

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: 28 October 2025 14:04
> To: Eric Auger <eric.auger@redhat.com>
> Cc: Nicolin Chen <nicolinc@nvidia.com>; Shameer Kolothum
> <skolothumtho@nvidia.com>; qemu-arm@nongnu.org; qemu-
> devel@nongnu.org; peter.maydell@linaro.org; ddutile@redhat.com;
> berrange@redhat.com; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
> <mochs@nvidia.com>; smostafa@google.com; wangzhou1@hisilicon.com;
> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
> shameerkolothum@gmail.com
> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
> 
> On Tue, Oct 28, 2025 at 02:51:29PM +0100, Eric Auger wrote:
> >
> >
> > On 10/28/25 2:41 PM, Jason Gunthorpe wrote:
> > > On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
> > >>
> > >> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
> > >>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
> > >>>
> > >>>> Hmm, that sounds a legit reason, though adding the ATS support to
> > >>>> the emulated SMMUv3 isn't seemingly a small effort...
> > >>> What is "emulated ATS" anyhow?
> > >> I guess it means implementing ATS translation requests and capability to
> > >> send ATS invalidations. something like:
> > >>
> > >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
> kernel.org%2Fall%2F20250628180226.133285-1-clement.mathieu--
> drif%40eviden.com%2F&data=05%7C02%7Cskolothumtho%40nvidia.com%
> 7C9f9c8fc639214f54ca0808de162accab%7C43083d15727340c1b7db39efd
> 9ccc17a%7C0%7C0%7C638972570246014005%7CUnknown%7CTWFpbGZs
> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YQfzKiIcBbKj
> kIauHU8ELDk15jclFnFcevMMRf7LHF0%3D&reserved=0
> > > Why would you even want this? The cover letter didn't explain what the
> > > point was.
> >
> > well I am just concerned about exposing ATS support to emulated EPs
> > while we actually do not support it.
> 
> Sure, that shouldn't be done. There is ACPI/DT tables indicating if the
> each device supports ATS and qemu should not be marking the emulated
> EPs as ATS capable in the first place..
> 
> However, there is no big work with showing EPs as ATS capable. They
> don't implement an ATC and there is no concept of "translated address"
> inside qemu so the only requirement to make it "work" is to just NOP
> the ATC invalidation SMMU commands for those EPs.

The only case where an emulated endpoint can appear with SMMUv3
accel enabled is during a hot-plug scenario.

As mentioned elsewhere in this discussion, that can be handled by propagating
an error from the pci_device_iommu_address_space() path.

I will take a look at that if this is the main concern regarding ATS.

Thanks,
Shameer

On 10/28/25 3:44 PM, Shameer Kolothum wrote:
>
>> -----Original Message-----
>> From: Jason Gunthorpe <jgg@nvidia.com>
>> Sent: 28 October 2025 14:04
>> To: Eric Auger <eric.auger@redhat.com>
>> Cc: Nicolin Chen <nicolinc@nvidia.com>; Shameer Kolothum
>> <skolothumtho@nvidia.com>; qemu-arm@nongnu.org; qemu-
>> devel@nongnu.org; peter.maydell@linaro.org; ddutile@redhat.com;
>> berrange@redhat.com; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
>> <mochs@nvidia.com>; smostafa@google.com; wangzhou1@hisilicon.com;
>> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
>> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
>> shameerkolothum@gmail.com
>> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
>>
>> On Tue, Oct 28, 2025 at 02:51:29PM +0100, Eric Auger wrote:
>>>
>>> On 10/28/25 2:41 PM, Jason Gunthorpe wrote:
>>>> On Tue, Oct 28, 2025 at 02:21:32PM +0100, Eric Auger wrote:
>>>>> On 10/28/25 1:16 PM, Jason Gunthorpe wrote:
>>>>>> On Mon, Oct 27, 2025 at 10:53:10AM -0700, Nicolin Chen wrote:
>>>>>>
>>>>>>> Hmm, that sounds a legit reason, though adding the ATS support to
>>>>>>> the emulated SMMUv3 isn't seemingly a small effort...
>>>>>> What is "emulated ATS" anyhow?
>>>>> I guess it means implementing ATS translation requests and capability to
>>>>> send ATS invalidations. something like:
>>>>>
>>>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
>> kernel.org%2Fall%2F20250628180226.133285-1-clement.mathieu--
>> drif%40eviden.com%2F&data=05%7C02%7Cskolothumtho%40nvidia.com%
>> 7C9f9c8fc639214f54ca0808de162accab%7C43083d15727340c1b7db39efd
>> 9ccc17a%7C0%7C0%7C638972570246014005%7CUnknown%7CTWFpbGZs
>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YQfzKiIcBbKj
>> kIauHU8ELDk15jclFnFcevMMRf7LHF0%3D&reserved=0
>>>> Why would you even want this? The cover letter didn't explain what the
>>>> point was.
>>> well I am just concerned about exposing ATS support to emulated EPs
>>> while we actually do not support it.
>> Sure, that shouldn't be done. There is ACPI/DT tables indicating if the
>> each device supports ATS and qemu should not be marking the emulated
>> EPs as ATS capable in the first place..
>>
>> However, there is no big work with showing EPs as ATS capable. They
>> don't implement an ATC and there is no concept of "translated address"
>> inside qemu so the only requirement to make it "work" is to just NOP
>> the ATC invalidation SMMU commands for those EPs.
> The only case where an emulated endpoint can appear with SMMUv3
> accel enabled is during a hot-plug scenario.
>
> As mentioned elsewhere in this discussion, that can be handled by propagating
> an error from the pci_device_iommu_address_space() path.
>
> I will take a look at that if this is the main concern regarding ATS.
OK thanks!

Eric
>
> Thanks,
> Shameer
>

> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: 27 October 2025 17:38
> To: Nicolin Chen <nicolinc@nvidia.com>
> Cc: Shameer Kolothum <skolothumtho@nvidia.com>; qemu-
> arm@nongnu.org; qemu-devel@nongnu.org; peter.maydell@linaro.org;
> Jason Gunthorpe <jgg@nvidia.com>; ddutile@redhat.com;
> berrange@redhat.com; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
> <mochs@nvidia.com>; smostafa@google.com; wangzhou1@hisilicon.com;
> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
> shameerkolothum@gmail.com
> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
> 
> External email: Use caution opening links or attachments
> 
> 
> On 10/27/25 6:13 PM, Nicolin Chen wrote:
> > Hi Eric,
> >
> > On Mon, Oct 27, 2025 at 05:59:13PM +0100, Eric Auger wrote:
> >> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
> >>> QEMU SMMUv3 does not enable ATS (Address Translation Services) by
> default.
> >>> When accelerated mode is enabled and the host SMMUv3 supports ATS, it
> can
> >>> be useful to report ATS capability to the guest so it can take advantage
> >>> of it if the device also supports ATS.
> >>>
> >>> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> >>> registers alone, as firmware ACPI IORT tables may override them. The
> >>> user must therefore ensure the support before enabling it.
> >> This looks incomplete to me. ATS is a big topic in itself. I would
> >> prefer we do not advertise it until we do not have full support for it
> >> (including emulation). Comparing to
> >> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
> >> contributed we miss at least translation request implementations
> >> (PCIIOMMUOps ats_request_translation callback implementation).
> >>
> >> See:
> >> https://lore.kernel.org/all/20250628180226.133285-11-
> clement.mathieu--drif@eviden.com/#r
> > In accelerated SMMUv3 case, ATS translation and invalidation are
> > done by the physical SMMU. Wondering why do we need this?
> 
> in 06/27 you still can have emulated EPs hotplugged in the loop, no?

That can be prevented by propagating an error from the get_address_space()
callback. It’s already on my TODO list as a follow-up series, but I can move it
forward if this is a major concern here.

> 
> I remember some discussions with Peter who was also reluctant in general
> to introduce some partial feature support. I think in general this is a
> good policy to have features emulated and then accelerated. That's also
> good for testing in case we can bring up some test env.

Understood. However, ATS and PASID are the two key features required to make
any meaningful use of the accelerated support. I’m not suggesting we skip
emulation for ATS or PASID entirely, just that we prioritize the acceleration
path first. 😊

Please let me know if there are any strong opinions on this.

Thanks,
Shameer

On 10/27/25 6:54 PM, Shameer Kolothum wrote:
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: 27 October 2025 17:38
>> To: Nicolin Chen <nicolinc@nvidia.com>
>> Cc: Shameer Kolothum <skolothumtho@nvidia.com>; qemu-
>> arm@nongnu.org; qemu-devel@nongnu.org; peter.maydell@linaro.org;
>> Jason Gunthorpe <jgg@nvidia.com>; ddutile@redhat.com;
>> berrange@redhat.com; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
>> <mochs@nvidia.com>; smostafa@google.com; wangzhou1@hisilicon.com;
>> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
>> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
>> shameerkolothum@gmail.com
>> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 10/27/25 6:13 PM, Nicolin Chen wrote:
>>> Hi Eric,
>>>
>>> On Mon, Oct 27, 2025 at 05:59:13PM +0100, Eric Auger wrote:
>>>> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
>>>>> QEMU SMMUv3 does not enable ATS (Address Translation Services) by
>> default.
>>>>> When accelerated mode is enabled and the host SMMUv3 supports ATS, it
>> can
>>>>> be useful to report ATS capability to the guest so it can take advantage
>>>>> of it if the device also supports ATS.
>>>>>
>>>>> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
>>>>> registers alone, as firmware ACPI IORT tables may override them. The
>>>>> user must therefore ensure the support before enabling it.
>>>> This looks incomplete to me. ATS is a big topic in itself. I would
>>>> prefer we do not advertise it until we do not have full support for it
>>>> (including emulation). Comparing to
>>>> c049bf5bb9dd ("intel_iommu: Add support for ATS") which was recently
>>>> contributed we miss at least translation request implementations
>>>> (PCIIOMMUOps ats_request_translation callback implementation).
>>>>
>>>> See:
>>>> https://lore.kernel.org/all/20250628180226.133285-11-
>> clement.mathieu--drif@eviden.com/#r
>>> In accelerated SMMUv3 case, ATS translation and invalidation are
>>> done by the physical SMMU. Wondering why do we need this?
>> in 06/27 you still can have emulated EPs hotplugged in the loop, no?
> That can be prevented by propagating an error from the get_address_space()
> callback. It’s already on my TODO list as a follow-up series, but I can move it
> forward if this is a major concern here.
>
>> I remember some discussions with Peter who was also reluctant in general
>> to introduce some partial feature support. I think in general this is a
>> good policy to have features emulated and then accelerated. That's also
>> good for testing in case we can bring up some test env.
> Understood. However, ATS and PASID are the two key features required to make
> any meaningful use of the accelerated support. I’m not suggesting we skip
> emulation for ATS or PASID entirely, just that we prioritize the acceleration
> path first. 😊
I understand this is needed for vSVA. Nevertheless accel SMMU can
already work and be tested in a stdalone manner without ATS and PASID.
Those 2 features add a significant complexity on top of the core series
including from the review pov. This partial support support is not
necessarily great. Also I have not closely followed the thread related
to "[PATCH v4 26/27] vfio: Synthesize vPASID capability to VM" touching
pci.c. I don't know how much this is contreversial. just reading the
commit msg frightens me a little bit: "This is a choice in the good hope
of no conflict with any existing cap or hidden registers" ;-) Eric
>
> Please let me know if there are any strong opinions on this.
>
> Thanks,
> Shameer

Hi Eric,

> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: 27 October 2025 18:03
> To: Shameer Kolothum <skolothumtho@nvidia.com>; Nicolin Chen
> <nicolinc@nvidia.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
> peter.maydell@linaro.org; Jason Gunthorpe <jgg@nvidia.com>;
> ddutile@redhat.com; berrange@redhat.com; Nathan Chen
> <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>;
> smostafa@google.com; wangzhou1@hisilicon.com;
> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
> shameerkolothum@gmail.com
> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
> 
> External email: Use caution opening links or attachments
> 
> 
> On 10/27/25 6:54 PM, Shameer Kolothum wrote:
> >
> >> -----Original Message-----
> >> From: Eric Auger <eric.auger@redhat.com>
> >> Sent: 27 October 2025 17:38
> >> To: Nicolin Chen <nicolinc@nvidia.com>
> >> Cc: Shameer Kolothum <skolothumtho@nvidia.com>; qemu-
> >> arm@nongnu.org; qemu-devel@nongnu.org; peter.maydell@linaro.org;
> >> Jason Gunthorpe <jgg@nvidia.com>; ddutile@redhat.com;
> >> berrange@redhat.com; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
> >> <mochs@nvidia.com>; smostafa@google.com; wangzhou1@hisilicon.com;
> >> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
> >> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
> >> shameerkolothum@gmail.com
> >> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS
> >>

[...]

> >> I remember some discussions with Peter who was also reluctant in general
> >> to introduce some partial feature support. I think in general this is a
> >> good policy to have features emulated and then accelerated. That's also
> >> good for testing in case we can bring up some test env.
> > Understood. However, ATS and PASID are the two key features required to
> make
> > any meaningful use of the accelerated support. I’m not suggesting we skip
> > emulation for ATS or PASID entirely, just that we prioritize the acceleration
> > path first. 😊
> I understand this is needed for vSVA. Nevertheless accel SMMU can
> already work and be tested in a stdalone manner without ATS and PASID.
> Those 2 features add a significant complexity on top of the core series
> including from the review pov. This partial support support is not
> necessarily great. Also I have not closely followed the thread related
> to "[PATCH v4 26/27] vfio: Synthesize vPASID capability to VM" touching
> pci.c. I don't know how much this is contreversial. just reading the
> commit msg frightens me a little bit: "This is a choice in the good hope
> of no conflict with any existing cap or hidden registers" ;

Regarding PASID, that concern only applies if we were to blindly use the last
8 bytes of the virtual config space to place the PASID capability. In this
implementation, we only synthesize the PASID capability when the device is
behind a vSMMUv3 with accel=on. The user explicitly controls which devices
have this capability synthesized.

I don’t think this poses a major risk.

Thanks,
Shameer

On Mon, 29 Sep 2025 14:36:38 +0100
Shameer Kolothum <skolothumtho@nvidia.com> wrote:

> QEMU SMMUv3 does not enable ATS (Address Translation Services) by default.
> When accelerated mode is enabled and the host SMMUv3 supports ATS, it can
> be useful to report ATS capability to the guest so it can take advantage
> of it if the device also supports ATS.
> 
> Note: ATS support cannot be reliably detected from the host SMMUv3 IDR
> registers alone, as firmware ACPI IORT tables may override them. The
> user must therefore ensure the support before enabling it.
> 
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Trivial stuff only.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

Feels like there should be some host mechanism we could query
for support but if not I guess the 'don't set it wrong' comment
is the best we can do.

> ---
>  hw/arm/smmuv3-accel.c    |  4 ++++
>  hw/arm/smmuv3.c          | 25 ++++++++++++++++++++++++-
>  hw/arm/virt-acpi-build.c | 10 ++++++++--
>  include/hw/arm/smmuv3.h  |  1 +
>  4 files changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
> index e8607b253e..eee54316bf 100644
> --- a/hw/arm/smmuv3-accel.c
> +++ b/hw/arm/smmuv3-accel.c
> @@ -644,6 +644,10 @@ void smmuv3_accel_idr_override(SMMUv3State *s)
>      if (!s->ril) {
>          s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 0);
>      }
> +    /* QEMU SMMUv3 has no ATS. Update IDR0 if user has enabled it */
> +    if (s->ats) {
> +        s->idr[0] = FIELD_DP32(s->idr[0], IDR0, ATS, 1); /* ATS */

Not sure the comment adds anything given the field name!

> +    }
>  }
>  
>  /*
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 0f3a61646a..77d46a9cd6 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -1510,13 +1510,28 @@ static int smmuv3_cmdq_consume(SMMUv3State *s)
>               */
>              smmuv3_range_inval(bs, &cmd, SMMU_STAGE_2);
>              break;
> +        case SMMU_CMD_ATC_INV:
> +        {
> +            SMMUDevice *sdev = smmu_find_sdev(bs, CMD_SID(&cmd));
> +            Error *local_err = NULL;
> +
> +            if (!sdev) {
> +                break;
> +            }
> +
> +            if (!smmuv3_accel_issue_inv_cmd(s, &cmd, sdev, &local_err)) {
> +                error_report_err(local_err);
> +                cmd_error = SMMU_CERROR_ILL;
> +                break;
> +            }
> +            break;
> +        }
>          case SMMU_CMD_TLBI_EL3_ALL:
>          case SMMU_CMD_TLBI_EL3_VA:
>          case SMMU_CMD_TLBI_EL2_ALL:
>          case SMMU_CMD_TLBI_EL2_ASID:
>          case SMMU_CMD_TLBI_EL2_VA:
>          case SMMU_CMD_TLBI_EL2_VAA:
> -        case SMMU_CMD_ATC_INV:
>          case SMMU_CMD_PRI_RESP:
>          case SMMU_CMD_RESUME:
>          case SMMU_CMD_STALL_TERM:
> @@ -1934,6 +1949,10 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
>          error_setg(errp, "ril can only be disabled if accel=on");
>          return false;
>      }
> +    if (s->ats) {
> +        error_setg(errp, "ats can only be enabled if accel=on");
> +        return false;

Comment in previous patch follow through here...

> +    }
>      return true;
>  }

> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index d0c1e10019..a53f0229b8 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c