[PATCH for-11.0 v5 0/8] hw/arm/smmuv3-accel: Support AUTO properties

Nathan Chen posted 8 patches 1 week, 3 days ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20260323182454.1416110-1-nathanc@nvidia.com
Maintainers: Eric Auger <eric.auger@redhat.com>, Peter Maydell <peter.maydell@linaro.org>, Shannon Zhao <shannon.zhaosl@gmail.com>, "Michael S. Tsirkin" <mst@redhat.com>, Igor Mammedov <imammedo@redhat.com>, Ani Sinha <anisinha@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>
hw/arm/smmuv3-accel.c                    | 41 ++++++++++++---
hw/arm/smmuv3.c                          | 64 +++++++++++++++---------
hw/arm/virt-acpi-build.c                 |  2 +-
hw/core/qdev-properties-system.c         | 27 ++++++++++
include/hw/arm/smmuv3-common.h           |  3 --
include/hw/arm/smmuv3.h                  | 11 ++--
include/hw/core/qdev-properties-system.h |  6 +++
qapi/misc-arm.json                       | 44 ++++++++++++++++
qapi/pragma.json                         |  1 +
qemu-options.hx                          | 32 +++++++++++-
10 files changed, 193 insertions(+), 38 deletions(-)
[PATCH for-11.0 v5 0/8] hw/arm/smmuv3-accel: Support AUTO properties
Posted by Nathan Chen 1 week, 3 days ago
Hi,

This is a follow-up to the previous series [0] that introduces support
for specifying 'auto' for arm-smmuv3 accelerated mode's ATS, RIL,
SSIDSIZE, and OAS feature properties.

In QEMU 11.0 we introduced new options for vSMMU [1], but feedback received
when starting the integration of layered products shows the need for
auto/host-retrieved values. To avoid breaking JSON/QMP compat, we want
to fix the option types so that they can later support the auto mode. At
the moment the auto mode is not supported though.

A future series will introduce support for resolving the 'auto' values
based on host SMMUv3 IDR values, as well as setting per-device ATS
capability.

A complete branch can be found here:
https://github.com/NathanChenNVIDIA/qemu/tree/smmuv3-accel-auto-v5

Please take a look and let me know your feedback.

Thanks,
Nathan

Changes from v4:
- Revise OAS validation error message
- Revise SsidSizeMode enum ordering comment
- Revise commit titles and descriptions to mention incompatible change
  and change to 'property type' instead of 'property'.
- Collected R-by, T-by, A-by tags from v4, thanks Eric, Shameer, and
  Markus!

Changes from v3:
- Revise auto support error message
- Restore original comment for ATS in smmuv3_accel_idr_override()
- Update the description in object_class_property_set_description()
  to mention auto mode not supported.
- Move auto mode check before check for accel=on
- Remove SMMU_OAS_44BIT/_48BIT and SMMU_SSID_MAX_BITS defines
- Consolidate documentation notes about properties only being
  available for accel=on and not supporting auto mode.
- Include R-by and T-by tags from v3, thanks Eric and Shameer!

Changes from v2:
- Enforce 'auto' value not being supported for HW-accel SMMUv3 props
- Revise docs to mention auto is not supported and these properties
  are only applicable when accel=on.
- Only override non-defaults in smmuv3_accel_idr_override()
- Remove check for SSIDSIZE AUTO in smmuv3_accel_idr_override() as
  smmu_validate_property() checks for AUTO beforehand
- Consolidate comments for ssidsize_mode_to_value()
- Include Fixes tags in commit descriptions
- Include R-by tags from v2

Changes from RFCv1:
- Remove changes that resolve the 'auto' values based on host SMMUv3
- Restore defaults values for RIL, OAS, SSIDSIZE, and ATS
- Update OasMode to accept all OAS sizes instead of only auto, 44, and
  48
- Include comment in SsidSizeMode schema clarifying enum value
  ordering
- Replace ats-enabled prop with a helper that accepts the dynamic
  casted TYPE_ARM_SMMUV3 object
- Separate out guest vs. host ATS check in
  smmuv3_accel_check_hw_compatible() to a different commit
- Document accel, RIL, OAS, SSIDSIZE, and ATS properties in
  qemu-options.hx

Testing:
Basic sanity testing was performed on an NVIDIA Grace platform with GPU
device assignment and running CUDA test apps on the guest. Additional
testing and feedback are welcome.

[0] https://lore.kernel.org/all/20260318184907.4060030-1-nathanc@nvidia.com/
[1] https://lore.kernel.org/all/20260126104342.253965-1-skolothumtho@nvidia.com/

Nathan Chen (8):
  hw/arm/smmuv3-accel: Check ATS compatibility between host and guest
  hw/arm/smmuv3-accel: Change "ats" property type to OnOffAuto
  hw/arm/smmuv3-accel: Change "ril" property type to OnOffAuto
  qdev: Add a SsidSizeMode property type
  hw/arm/smmuv3-accel: Change "ssidsize" property type to SsidSizeMode
  qdev: Add an OasMode property type
  hw/arm/smmuv3-accel: Change "oas" property type to OasMode
  qemu-options.hx: Document arm-smmuv3 device's accel properties

 hw/arm/smmuv3-accel.c                    | 41 ++++++++++++---
 hw/arm/smmuv3.c                          | 64 +++++++++++++++---------
 hw/arm/virt-acpi-build.c                 |  2 +-
 hw/core/qdev-properties-system.c         | 27 ++++++++++
 include/hw/arm/smmuv3-common.h           |  3 --
 include/hw/arm/smmuv3.h                  | 11 ++--
 include/hw/core/qdev-properties-system.h |  6 +++
 qapi/misc-arm.json                       | 44 ++++++++++++++++
 qapi/pragma.json                         |  1 +
 qemu-options.hx                          | 32 +++++++++++-
 10 files changed, 193 insertions(+), 38 deletions(-)

-- 
2.43.0
Re: [PATCH for-11.0 v5 0/8] hw/arm/smmuv3-accel: Support AUTO properties
Posted by Peter Maydell 1 week, 3 days ago
On Mon, 23 Mar 2026 at 18:25, Nathan Chen <nathanc@nvidia.com> wrote:
>
> Hi,
>
> This is a follow-up to the previous series [0] that introduces support
> for specifying 'auto' for arm-smmuv3 accelerated mode's ATS, RIL,
> SSIDSIZE, and OAS feature properties.
>
> In QEMU 11.0 we introduced new options for vSMMU [1], but feedback received
> when starting the integration of layered products shows the need for
> auto/host-retrieved values. To avoid breaking JSON/QMP compat, we want
> to fix the option types so that they can later support the auto mode. At
> the moment the auto mode is not supported though.
>
> A future series will introduce support for resolving the 'auto' values
> based on host SMMUv3 IDR values, as well as setting per-device ATS
> capability.

Hi; I'm picking this up for target-arm.next because it looks to
me like it's been reviewed, and it seems to me better to take it
for rc1 and if necessary make any last minor tweaks with a
separate patch in rc2, rather than let it sit on list for a bit
longer and take the whole thing in rc2.

Let me know if you'd rather it wait longer.

thanks
-- PMM
Re: [PATCH for-11.0 v5 0/8] hw/arm/smmuv3-accel: Support AUTO properties
Posted by Nathan Chen 1 week, 2 days ago

On 3/24/2026 6:30 AM, Peter Maydell wrote:
> On Mon, 23 Mar 2026 at 18:25, Nathan Chen<nathanc@nvidia.com> wrote:
>> Hi,
>>
>> This is a follow-up to the previous series [0] that introduces support
>> for specifying 'auto' for arm-smmuv3 accelerated mode's ATS, RIL,
>> SSIDSIZE, and OAS feature properties.
>>
>> In QEMU 11.0 we introduced new options for vSMMU [1], but feedback received
>> when starting the integration of layered products shows the need for
>> auto/host-retrieved values. To avoid breaking JSON/QMP compat, we want
>> to fix the option types so that they can later support the auto mode. At
>> the moment the auto mode is not supported though.
>>
>> A future series will introduce support for resolving the 'auto' values
>> based on host SMMUv3 IDR values, as well as setting per-device ATS
>> capability.
> Hi; I'm picking this up for target-arm.next because it looks to
> me like it's been reviewed, and it seems to me better to take it
> for rc1 and if necessary make any last minor tweaks with a
> separate patch in rc2, rather than let it sit on list for a bit
> longer and take the whole thing in rc2.
> 
> Let me know if you'd rather it wait longer.

Hi, I also think it makes sense to pick it up for rc1 as all review 
comments so far have been addressed in this refresh.

Thanks,
Nathan