QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
With accelerator mode enabled, a device may use SVA, where CPU page tables
are shared with the SMMU, requiring an OAS at least as large as the
CPU’s output address size. A user option is added to configure this.

However, the OAS value advertised by the virtual SMMU must remain
compatible with the capabilities of the host SMMUv3. In accelerated
mode, the host SMMU performs stage-2 translation and must be able to
consume the intermediate physical addresses (IPA) produced by stage-1.

The OAS exposed by the virtual SMMU defines the maximum IPA width that
stage-1 translations may generate. For AArch64 implementations, the
maximum usable IPA size on the host SMMU is determined by its own OAS.
Check that the configured OAS does not exceed what the host SMMU
can safely support.

Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
 hw/arm/smmuv3-accel.c          | 22 ++++++++++++++++++++++
 hw/arm/smmuv3.c                | 16 +++++++++++++++-
 include/hw/arm/smmuv3-common.h |  5 ++++-
 include/hw/arm/smmuv3.h        |  1 +
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
index a97abc1f79..ea420afeb7 100644
--- a/hw/arm/smmuv3-accel.c
+++ b/hw/arm/smmuv3-accel.c
@@ -27,6 +27,14 @@
 static MemoryRegion root, sysmem;
 static AddressSpace *shared_as_sysmem;
 
+static int smmuv3_oas_bits(uint32_t oas)
+{
+    static const int map[] = { 32, 36, 40, 42, 44, 48, 52, 56 };
+
+    g_assert(oas < ARRAY_SIZE(map));
+    return map[oas];
+}
+
 static bool
 smmuv3_accel_check_hw_compatible(SMMUv3State *s,
                                  struct iommu_hw_info_arm_smmuv3 *info,
@@ -74,6 +82,15 @@ smmuv3_accel_check_hw_compatible(SMMUv3State *s,
         error_setg(errp, "Host SMMUv3 doesn't support Range Invalidation");
         return false;
     }
+    /* Check OAS value opted is compatible with Host SMMUv3 IPA */
+    if (FIELD_EX32(info->idr[5], IDR5, OAS) <
+                FIELD_EX32(s->idr[5], IDR5, OAS)) {
+        error_setg(errp, "Host SMMUv3 supports only %d-bit IPA, but the vSMMU "
+                   "OAS implies %d-bit IPA",
+                   smmuv3_oas_bits(FIELD_EX32(info->idr[5], IDR5, OAS)),
+                   smmuv3_oas_bits(FIELD_EX32(s->idr[5], IDR5, OAS)));
+        return false;
+    }
 
     /* QEMU SMMUv3 supports GRAN4K/GRAN16K/GRAN64K translation granules */
     if (FIELD_EX32(info->idr[5], IDR5, GRAN4K) !=
@@ -657,6 +674,11 @@ void smmuv3_accel_idr_override(SMMUv3State *s)
 
     /* QEMU SMMUv3 has no ATS. Advertise ATS if opt-in by property */
     s->idr[0] = FIELD_DP32(s->idr[0], IDR0, ATS, s->ats);
+
+    /* Advertise 48-bit OAS in IDR5 when requested (default is 44 bits). */
+    if (s->oas == SMMU_OAS_48BIT) {
+        s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS_48);
+    }
 }
 
 /* Based on SMUUv3 GPBA.ABORT configuration, attach a corresponding HWPT */
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index ca086ba00a..cb02184d2d 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -299,7 +299,8 @@ static void smmuv3_init_id_regs(SMMUv3State *s)
     s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 1);
     s->idr[3] = FIELD_DP32(s->idr[3], IDR3, BBML, 2);
 
-    s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS); /* 44 bits */
+    /* OAS: 44 bits */
+    s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS_44);
     /* 4K, 16K and 64K granule support */
     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, 1);
     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN16K, 1);
@@ -1949,6 +1950,10 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
             error_setg(errp, "ats can only be enabled if accel=on");
             return false;
         }
+        if (s->oas != SMMU_OAS_44BIT) {
+            error_setg(errp, "OAS must be 44 bits when accel=off");
+            return false;
+        }
         return true;
     }
 
@@ -1959,6 +1964,11 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
         return false;
     }
 
+    if (s->oas != SMMU_OAS_44BIT && s->oas != SMMU_OAS_48BIT) {
+        error_setg(errp, "OAS can only be set to 44 or 48 bits");
+        return false;
+    }
+
     return true;
 }
 
@@ -2085,6 +2095,7 @@ static const Property smmuv3_properties[] = {
     /* RIL can be turned off for accel cases */
     DEFINE_PROP_BOOL("ril", SMMUv3State, ril, true),
     DEFINE_PROP_BOOL("ats", SMMUv3State, ats, false),
+    DEFINE_PROP_UINT8("oas", SMMUv3State, oas, 44),
 };
 
 static void smmuv3_instance_init(Object *obj)
@@ -2115,6 +2126,9 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
     object_class_property_set_description(klass, "ats",
         "Enable/disable ATS support (for accel=on). Please ensure host "
         "platform has ATS support before enabling this");
+    object_class_property_set_description(klass, "oas",
+        "Specify Output Address Size (for accel=on). Supported values "
+        "are 44 or 48 bits. Defaults to 44 bits");
 }
 
 static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
diff --git a/include/hw/arm/smmuv3-common.h b/include/hw/arm/smmuv3-common.h
index 415b7ccde5..abe3565357 100644
--- a/include/hw/arm/smmuv3-common.h
+++ b/include/hw/arm/smmuv3-common.h
@@ -342,7 +342,10 @@ REG32(IDR5,                0x14)
      FIELD(IDR5, VAX,        10, 2);
      FIELD(IDR5, STALL_MAX,  16, 16);
 
-#define SMMU_IDR5_OAS 4
+#define SMMU_OAS_44BIT 44
+#define SMMU_OAS_48BIT 48
+#define SMMU_IDR5_OAS_44 4
+#define SMMU_IDR5_OAS_48 5
 
 REG32(IIDR,                0x18)
 REG32(AIDR,                0x1c)
diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
index 242d6429ed..d488a39cd0 100644
--- a/include/hw/arm/smmuv3.h
+++ b/include/hw/arm/smmuv3.h
@@ -71,6 +71,7 @@ struct SMMUv3State {
     Error *migration_blocker;
     bool ril;
     bool ats;
+    uint8_t oas;
 };
 
 typedef enum {
-- 
2.43.0

Hi Shameer, Nicolin,
On 1/26/26 11:43 AM, Shameer Kolothum wrote:
> QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
> With accelerator mode enabled, a device may use SVA, where CPU page tables
> are shared with the SMMU, requiring an OAS at least as large as the
> CPU’s output address size. A user option is added to configure this.
>
> However, the OAS value advertised by the virtual SMMU must remain
> compatible with the capabilities of the host SMMUv3. In accelerated
> mode, the host SMMU performs stage-2 translation and must be able to
> consume the intermediate physical addresses (IPA) produced by stage-1.
>
> The OAS exposed by the virtual SMMU defines the maximum IPA width that
> stage-1 translations may generate. For AArch64 implementations, the
> maximum usable IPA size on the host SMMU is determined by its own OAS.
> Check that the configured OAS does not exceed what the host SMMU
> can safely support.

After discussion with Kubevirt guys, the management of current RIL,
ssidsize, ats and oas options look touchy because it is tricky for them
to introspect the host values.

In cold plug case at least it looks feasible to use IOMMU_GET_HW_INFO()
to retrieve host info:

RIL is in IDR3
ssidsize in IDR1
OAS in IDR5
ATS may be more touchy but maybe this can be introspected too?

I would advocate to turn those options into _AUTO options to give a
chance to the user to ask for host derived values.

Currently in include/hw/qdev-properties.h we have
DEFINE_PROP_ON_OFF_AUTO for a bool and
DEFINE_PROP_ON_OFF_AUTO_BIT64 for a 64b

RIL can match bool.
Others may need a new DEFINE_PROP_ON_OFF_AUTO_* one.

Note such kind of auto property was introduced for virtio-iommu
(DEFINE_PROP_GRANULE_MODE)

What do you think? Most probably this has been dicussed in the past but
I do not necessarily remember the outputs.

Thanks

Eric



>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Tested-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  hw/arm/smmuv3-accel.c          | 22 ++++++++++++++++++++++
>  hw/arm/smmuv3.c                | 16 +++++++++++++++-
>  include/hw/arm/smmuv3-common.h |  5 ++++-
>  include/hw/arm/smmuv3.h        |  1 +
>  4 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
> index a97abc1f79..ea420afeb7 100644
> --- a/hw/arm/smmuv3-accel.c
> +++ b/hw/arm/smmuv3-accel.c
> @@ -27,6 +27,14 @@
>  static MemoryRegion root, sysmem;
>  static AddressSpace *shared_as_sysmem;
>  
> +static int smmuv3_oas_bits(uint32_t oas)
> +{
> +    static const int map[] = { 32, 36, 40, 42, 44, 48, 52, 56 };
> +
> +    g_assert(oas < ARRAY_SIZE(map));
> +    return map[oas];
> +}
> +
>  static bool
>  smmuv3_accel_check_hw_compatible(SMMUv3State *s,
>                                   struct iommu_hw_info_arm_smmuv3 *info,
> @@ -74,6 +82,15 @@ smmuv3_accel_check_hw_compatible(SMMUv3State *s,
>          error_setg(errp, "Host SMMUv3 doesn't support Range Invalidation");
>          return false;
>      }
> +    /* Check OAS value opted is compatible with Host SMMUv3 IPA */
> +    if (FIELD_EX32(info->idr[5], IDR5, OAS) <
> +                FIELD_EX32(s->idr[5], IDR5, OAS)) {
> +        error_setg(errp, "Host SMMUv3 supports only %d-bit IPA, but the vSMMU "
> +                   "OAS implies %d-bit IPA",
> +                   smmuv3_oas_bits(FIELD_EX32(info->idr[5], IDR5, OAS)),
> +                   smmuv3_oas_bits(FIELD_EX32(s->idr[5], IDR5, OAS)));
> +        return false;
> +    }
>  
>      /* QEMU SMMUv3 supports GRAN4K/GRAN16K/GRAN64K translation granules */
>      if (FIELD_EX32(info->idr[5], IDR5, GRAN4K) !=
> @@ -657,6 +674,11 @@ void smmuv3_accel_idr_override(SMMUv3State *s)
>  
>      /* QEMU SMMUv3 has no ATS. Advertise ATS if opt-in by property */
>      s->idr[0] = FIELD_DP32(s->idr[0], IDR0, ATS, s->ats);
> +
> +    /* Advertise 48-bit OAS in IDR5 when requested (default is 44 bits). */
> +    if (s->oas == SMMU_OAS_48BIT) {
> +        s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS_48);
> +    }
>  }
>  
>  /* Based on SMUUv3 GPBA.ABORT configuration, attach a corresponding HWPT */
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index ca086ba00a..cb02184d2d 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -299,7 +299,8 @@ static void smmuv3_init_id_regs(SMMUv3State *s)
>      s->idr[3] = FIELD_DP32(s->idr[3], IDR3, RIL, 1);
>      s->idr[3] = FIELD_DP32(s->idr[3], IDR3, BBML, 2);
>  
> -    s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS); /* 44 bits */
> +    /* OAS: 44 bits */
> +    s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS_44);
>      /* 4K, 16K and 64K granule support */
>      s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, 1);
>      s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN16K, 1);
> @@ -1949,6 +1950,10 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
>              error_setg(errp, "ats can only be enabled if accel=on");
>              return false;
>          }
> +        if (s->oas != SMMU_OAS_44BIT) {
> +            error_setg(errp, "OAS must be 44 bits when accel=off");
> +            return false;
> +        }
>          return true;
>      }
>  
> @@ -1959,6 +1964,11 @@ static bool smmu_validate_property(SMMUv3State *s, Error **errp)
>          return false;
>      }
>  
> +    if (s->oas != SMMU_OAS_44BIT && s->oas != SMMU_OAS_48BIT) {
> +        error_setg(errp, "OAS can only be set to 44 or 48 bits");
> +        return false;
> +    }
> +
>      return true;
>  }
>  
> @@ -2085,6 +2095,7 @@ static const Property smmuv3_properties[] = {
>      /* RIL can be turned off for accel cases */
>      DEFINE_PROP_BOOL("ril", SMMUv3State, ril, true),
>      DEFINE_PROP_BOOL("ats", SMMUv3State, ats, false),
> +    DEFINE_PROP_UINT8("oas", SMMUv3State, oas, 44),
>  };
>  
>  static void smmuv3_instance_init(Object *obj)
> @@ -2115,6 +2126,9 @@ static void smmuv3_class_init(ObjectClass *klass, const void *data)
>      object_class_property_set_description(klass, "ats",
>          "Enable/disable ATS support (for accel=on). Please ensure host "
>          "platform has ATS support before enabling this");
> +    object_class_property_set_description(klass, "oas",
> +        "Specify Output Address Size (for accel=on). Supported values "
> +        "are 44 or 48 bits. Defaults to 44 bits");
>  }
>  
>  static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
> diff --git a/include/hw/arm/smmuv3-common.h b/include/hw/arm/smmuv3-common.h
> index 415b7ccde5..abe3565357 100644
> --- a/include/hw/arm/smmuv3-common.h
> +++ b/include/hw/arm/smmuv3-common.h
> @@ -342,7 +342,10 @@ REG32(IDR5,                0x14)
>       FIELD(IDR5, VAX,        10, 2);
>       FIELD(IDR5, STALL_MAX,  16, 16);
>  
> -#define SMMU_IDR5_OAS 4
> +#define SMMU_OAS_44BIT 44
> +#define SMMU_OAS_48BIT 48
> +#define SMMU_IDR5_OAS_44 4
> +#define SMMU_IDR5_OAS_48 5
>  
>  REG32(IIDR,                0x18)
>  REG32(AIDR,                0x1c)
> diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
> index 242d6429ed..d488a39cd0 100644
> --- a/include/hw/arm/smmuv3.h
> +++ b/include/hw/arm/smmuv3.h
> @@ -71,6 +71,7 @@ struct SMMUv3State {
>      Error *migration_blocker;
>      bool ril;
>      bool ats;
> +    uint8_t oas;
>  };
>  
>  typedef enum {

Hi Eric,

> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: 02 February 2026 14:40
> To: Shameer Kolothum Thodi <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;
> clg@redhat.com; alex@shazbot.org; 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; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH v9 31/37] hw/arm/smmuv3-accel: Add property to
> specify OAS bits
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Shameer, Nicolin,
> On 1/26/26 11:43 AM, Shameer Kolothum wrote:
> > QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
> > With accelerator mode enabled, a device may use SVA, where CPU page
> tables
> > are shared with the SMMU, requiring an OAS at least as large as the
> > CPU’s output address size. A user option is added to configure this.
> >
> > However, the OAS value advertised by the virtual SMMU must remain
> > compatible with the capabilities of the host SMMUv3. In accelerated
> > mode, the host SMMU performs stage-2 translation and must be able to
> > consume the intermediate physical addresses (IPA) produced by stage-1.
> >
> > The OAS exposed by the virtual SMMU defines the maximum IPA width that
> > stage-1 translations may generate. For AArch64 implementations, the
> > maximum usable IPA size on the host SMMU is determined by its own OAS.
> > Check that the configured OAS does not exceed what the host SMMU
> > can safely support.
> 
> After discussion with Kubevirt guys, the management of current RIL,
> ssidsize, ats and oas options look touchy because it is tricky for them
> to introspect the host values.

I may be wrong, but it looks like Kubevirt actually makes use of libvirt. Or
is it independent?

The reason I am asking is Nathan is already working on the libvirt changes 
for this here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5GG76AQTTDUHW5KRANPY3QUII4ZOEYRP/

And the _AUTO suggestion might impact that as well.
 
> In cold plug case at least it looks feasible to use IOMMU_GET_HW_INFO()
> to retrieve host info:
> 
> RIL is in IDR3
> ssidsize in IDR1
> OAS in IDR5
> ATS may be more touchy but maybe this can be introspected too?

Yeah. ATS might require some kernel plumbing as BIOS can override it.

> I would advocate to turn those options into _AUTO options to give a
> chance to the user to ask for host derived values.
> 
> Currently in include/hw/qdev-properties.h we have
> DEFINE_PROP_ON_OFF_AUTO for a bool and
> DEFINE_PROP_ON_OFF_AUTO_BIT64 for a 64b
> 
> RIL can match bool.
> Others may need a new DEFINE_PROP_ON_OFF_AUTO_* one.
> 
> Note such kind of auto property was introduced for virtio-iommu
> (DEFINE_PROP_GRANULE_MODE)
> 
> What do you think? Most probably this has been dicussed in the past but
> I do not necessarily remember the outputs.

IIRC, the only conclusion was that the user has to specify the SMMUv3
parameters.  Don't think the _AUTO option was discussed previously.
If this is a very useful thing to have, I can take a look.

Thanks,
Shameer

On 2/2/26 4:11 PM, Shameer Kolothum Thodi wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: 02 February 2026 14:40
>> To: Shameer Kolothum Thodi <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;
>> clg@redhat.com; alex@shazbot.org; 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; Krishnakant Jaju
>> <kjaju@nvidia.com>
>> Subject: Re: [PATCH v9 31/37] hw/arm/smmuv3-accel: Add property to
>> specify OAS bits
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Shameer, Nicolin,
>> On 1/26/26 11:43 AM, Shameer Kolothum wrote:
>>> QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
>>> With accelerator mode enabled, a device may use SVA, where CPU page
>> tables
>>> are shared with the SMMU, requiring an OAS at least as large as the
>>> CPU’s output address size. A user option is added to configure this.
>>>
>>> However, the OAS value advertised by the virtual SMMU must remain
>>> compatible with the capabilities of the host SMMUv3. In accelerated
>>> mode, the host SMMU performs stage-2 translation and must be able to
>>> consume the intermediate physical addresses (IPA) produced by stage-1.
>>>
>>> The OAS exposed by the virtual SMMU defines the maximum IPA width that
>>> stage-1 translations may generate. For AArch64 implementations, the
>>> maximum usable IPA size on the host SMMU is determined by its own OAS.
>>> Check that the configured OAS does not exceed what the host SMMU
>>> can safely support.
>> After discussion with Kubevirt guys, the management of current RIL,
>> ssidsize, ats and oas options look touchy because it is tricky for them
>> to introspect the host values.
> I may be wrong, but it looks like Kubevirt actually makes use of libvirt. Or
> is it independent?
yes they do? The problem is they don't know how to set the values for
those props besides definiting a kind of hardcoded profile. They are
unused to do that. The best would be to let qemu guess the right values
by introspection through the kernel uapi.
>
> The reason I am asking is Nathan is already working on the libvirt changes 
> for this here:
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5GG76AQTTDUHW5KRANPY3QUII4ZOEYRP/
>
> And the _AUTO suggestion might impact that as well.
sure. That's why I discuss it tight now.
>  
>> In cold plug case at least it looks feasible to use IOMMU_GET_HW_INFO()
>> to retrieve host info:
>>
>> RIL is in IDR3
>> ssidsize in IDR1
>> OAS in IDR5
>> ATS may be more touchy but maybe this can be introspected too?
> Yeah. ATS might require some kernel plumbing as BIOS can override it.
agreed
>
>> I would advocate to turn those options into _AUTO options to give a
>> chance to the user to ask for host derived values.
>>
>> Currently in include/hw/qdev-properties.h we have
>> DEFINE_PROP_ON_OFF_AUTO for a bool and
>> DEFINE_PROP_ON_OFF_AUTO_BIT64 for a 64b
>>
>> RIL can match bool.
>> Others may need a new DEFINE_PROP_ON_OFF_AUTO_* one.
>>
>> Note such kind of auto property was introduced for virtio-iommu
>> (DEFINE_PROP_GRANULE_MODE)
>>
>> What do you think? Most probably this has been dicussed in the past but
>> I do not necessarily remember the outputs.
> IIRC, the only conclusion was that the user has to specify the SMMUv3
> parameters.  Don't think the _AUTO option was discussed previously.
> If this is a very useful thing to have, I can take a look.
If this sounds feasible, I think this would be a more relevant approach.
The default values could be kept as is for now and we would let kubevirt
set AUTO value until the default gets changed.

Eric

>
> Thanks,
> Shameer

On Mon, Feb 02, 2026 at 03:11:28PM +0000, Shameer Kolothum Thodi wrote:
> > RIL is in IDR3
> > ssidsize in IDR1
> > OAS in IDR5
> > ATS may be more touchy but maybe this can be introspected too?
> 
> Yeah. ATS might require some kernel plumbing as BIOS can override it.

We can treat ATS as a per-PCIe device property.. I think it would be
fine to tell the SMMU that it always has ATS support, it will never do
anything with it unless it sees a PCIe device with an ATS cap, and the
physical STE generated by the hypervisor should sanitize the EATS.

BIOS overriding it should be reflected as the devices being reported
as not supporting ATS, qemu should have a per-device flag to disable
ATS.

Not sure that helps libvirt side though..

Jason

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: 02 February 2026 15:19
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Cc: eric.auger@redhat.com; qemu-arm@nongnu.org; qemu-
> devel@nongnu.org; peter.maydell@linaro.org; Nicolin Chen
> <nicolinc@nvidia.com>; ddutile@redhat.com; berrange@redhat.com;
> clg@redhat.com; alex@shazbot.org; 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; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH v9 31/37] hw/arm/smmuv3-accel: Add property to
> specify OAS bits
> 
> On Mon, Feb 02, 2026 at 03:11:28PM +0000, Shameer Kolothum Thodi
> wrote:
> > > RIL is in IDR3
> > > ssidsize in IDR1
> > > OAS in IDR5
> > > ATS may be more touchy but maybe this can be introspected too?
> >
> > Yeah. ATS might require some kernel plumbing as BIOS can override it.
> 
> We can treat ATS as a per-PCIe device property.. I think it would be
> fine to tell the SMMU that it always has ATS support, it will never do
> anything with it unless it sees a PCIe device with an ATS cap, and the
> physical STE generated by the hypervisor should sanitize the EATS.
> 
> BIOS overriding it should be reflected as the devices being reported
> as not supporting ATS, qemu should have a per-device flag to disable
> ATS.

Do we have way to detect that(IOMMU_FWSPEC_PCI_RC_ATS) from
userspace now?

Thanks,
Shameer

On Mon, Feb 02, 2026 at 03:38:50PM +0000, Shameer Kolothum Thodi wrote:

> > We can treat ATS as a per-PCIe device property.. I think it would be
> > fine to tell the SMMU that it always has ATS support, it will never do
> > anything with it unless it sees a PCIe device with an ATS cap, and the
> > physical STE generated by the hypervisor should sanitize the EATS.
> > 
> > BIOS overriding it should be reflected as the devices being reported
> > as not supporting ATS, qemu should have a per-device flag to disable
> > ATS.
> 
> Do we have way to detect that(IOMMU_FWSPEC_PCI_RC_ATS) from
> userspace now?

I don't think so.. I was describing how I suspect that should work.

The iommu driver is the only entity that decides if ATS should be
enabled per-device, so it should report back to userspace in iommufd
if the device is allowed to enable ATS or not. That should roll up any
FW overrides and the PCI cap block.

Jason

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: 02 February 2026 16:00
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Cc: eric.auger@redhat.com; qemu-arm@nongnu.org; qemu-
> devel@nongnu.org; peter.maydell@linaro.org; Nicolin Chen
> <nicolinc@nvidia.com>; ddutile@redhat.com; berrange@redhat.com;
> clg@redhat.com; alex@shazbot.org; 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; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH v9 31/37] hw/arm/smmuv3-accel: Add property to
> specify OAS bits
> 
> On Mon, Feb 02, 2026 at 03:38:50PM +0000, Shameer Kolothum Thodi
> wrote:
> 
> > > We can treat ATS as a per-PCIe device property.. I think it would be
> > > fine to tell the SMMU that it always has ATS support, it will never do
> > > anything with it unless it sees a PCIe device with an ATS cap, and the
> > > physical STE generated by the hypervisor should sanitize the EATS.
> > >
> > > BIOS overriding it should be reflected as the devices being reported
> > > as not supporting ATS, qemu should have a per-device flag to disable
> > > ATS.
> >
> > Do we have way to detect that(IOMMU_FWSPEC_PCI_RC_ATS) from
> > userspace now?
> 
> I don't think so.. I was describing how I suspect that should work.
> 
> The iommu driver is the only entity that decides if ATS should be
> enabled per-device, so it should report back to userspace in iommufd
> if the device is allowed to enable ATS or not. That should roll up any
> FW overrides and the PCI cap block.

Right. May be just like the out_max_pasid_log2. Will take a look.

Thanks,
Shameer