Re: [PATCH v10 4/6] qemu: introduce QEMU_CAPS_ARM_SMMUV3

6 Aug 2026

On 8/5/2026 5:22 AM, Pavel Hrdina wrote:
...
...
On Fri, Jul 17, 2026 at 03:00:23PM -0700, Nathan Chen via Devel wrote:
...
From: Nathan Chen<nathanc@nvidia.com>
The arm-smmuv3 QOM type appears in qom-list-types on ARM QEMU as far
back as 8.2 because the type is used for machine-integrated IOMMU
(-machine virt,iommu=smmuv3). That reply does not indicate support
for a user-pluggable -device arm-smmuv3.
User-pluggable SMMUv3 with the smmu_per_bus property was added in QEMU
10.2.0. Probe that property via device-list-properties instead of
registering arm-smmuv3 in virQEMUCapsObjectTypes[], so the capability
tracks pluggable device support rather than mere QOM visibility.
Skip arm-smmuv3 device-list-properties probing on non-ARM targets.
In qemu_validate.c, an IOMMU with pci_bus set requires
QEMU_CAPS_ARM_SMMUV3; machine-integrated SMMUv3 without pci_bus keeps
using QEMU_CAPS_MACHINE_VIRT_IOMMU.
Update caps_8.2.0_aarch64, caps_9.2.0_aarch64, caps_10.0.0_aarch64,
caps_10.2.0_aarch64, caps_11.0.0_aarch64, caps_8.2.0_armv7l, and
caps_11.1.0_aarch64 .replies with the arm-smmuv3 device-list-properties
exchange.
Signed-off-by: Nathan Chen<nathanc@nvidia.com>
---
  src/qemu/qemu_capabilities.c                  |  12 ++
  src/qemu/qemu_capabilities.h                  |   1 +
  src/qemu/qemu_validate.c                      |   9 +-
  .../caps_10.0.0_aarch64.replies               |  79 ++++++----
  .../caps_10.2.0_aarch64.replies               |  89 +++++++----
  .../caps_10.2.0_aarch64.xml                   |   1 +
  .../caps_11.0.0_aarch64.replies               | 132 ++++++++++++----
  .../caps_11.0.0_aarch64.xml                   |   1 +
  .../caps_11.1.0_aarch64.replies               | 143 ++++++++++++++----
  .../caps_11.1.0_aarch64.xml                   |   1 +
  .../caps_8.2.0_aarch64.replies                |  79 ++++++----
  .../caps_8.2.0_armv7l.replies                 |  79 ++++++----
  .../caps_9.2.0_aarch64+hvf.replies            |  75 ++++++---
  13 files changed, 514 insertions(+), 187 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index be57dcad8e..c98023bbe2 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -767,6 +767,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
/* 495 */
                "blockdev-mirror.target-is-zero", /* QEMU_CAPS_BLOCKDEV_MIRROR_TARGET_IS_ZERO */
+              "arm-smmuv3.smmu_per_bus", /* QEMU_CAPS_ARM_SMMUV3 */
IMO we should use QEMU_CAPS_ARM_SMMUV3_SMMU_PER_BUS as the capability name.
We support machine-wide smmuv3 for some time already so this could be
misleading.
...
);
@@ -1643,6 +1644,10 @@ static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsAMDIOMMU[] = {
      { "xtsup", QEMU_CAPS_AMD_IOMMU_XTSUP, NULL },
  };
+static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsArmSmmuv3[] = {
+    { "smmu_per_bus", QEMU_CAPS_ARM_SMMUV3, NULL },
+};
+
  /* see documentation for virQEMUQAPISchemaPathGet for the query format */
  static struct virQEMUCapsStringFlags virQEMUCapsQMPSchemaQueries[] = {
      { "blockdev-add/arg-type/+file/drop-cache", QEMU_CAPS_MIGRATION_FILE_DROP_CACHE },
@@ -1808,6 +1813,9 @@ static virQEMUCapsDeviceTypeProps virQEMUCapsDeviceProps[] = {
      { "amd-iommu", virQEMUCapsDevicePropsAMDIOMMU,
        G_N_ELEMENTS(virQEMUCapsDevicePropsAMDIOMMU),
        QEMU_CAPS_AMD_IOMMU },
+    { "arm-smmuv3", virQEMUCapsDevicePropsArmSmmuv3,
+      G_N_ELEMENTS(virQEMUCapsDevicePropsArmSmmuv3),
+      -1 },
      { "scsi-block", virQEMUCapsDevicePropsSCSIBlock,
        G_N_ELEMENTS(virQEMUCapsDevicePropsSCSIBlock),
        -1 },
@@ -2825,6 +2833,10 @@ virQEMUCapsProbeQMPDeviceProperties(virQEMUCaps *qemuCaps,
              !virQEMUCapsGet(qemuCaps, device->capsCondition))
              continue;
+        if (STREQ(device->type, "arm-smmuv3") &&
+            !ARCH_IS_ARM(qemuCaps->arch))
+            continue;
+
No need for this check, if qemu ever reports support for arm-smmuv3 on
different architecture that would be something qemu needs to fix.
I just realized that you've probably introduced this check so you don't
have to update all the *.replies files in our testing data. The correct
way is to introduce new capability that will check if `arm-smmuv3`
device is supported and in qemu_capabilities.c you will use the
QEMU_CAPS_DEVICE_SMMUV3 as a condition whether to query device
On Mon, Aug 03, 2026 at 01:57:29PM +0200, Pavel Hrdina via Devel wrote:
properties or not.
So you will need to introduce additional patch before the existing two
capabilities that will set QEMU_CAPS_DEVICE_SMMUV3 if `arm-smmuv3` is supported.
I see, I will add that additional patch for QEMU_CAPS_DEVICE_SMMUV3 and 
gate QEMU_CAPS_ARM_SMMUV3_SMMU_PER_BUS on it.

Thanks,
Nathan

    