On Mon, Aug 03, 2026 at 01:57:29PM +0200, Pavel Hrdina via Devel wrote: > On Fri, Jul 17, 2026 at 03:00:23PM -0700, Nathan Chen via Devel wrote: > > From: Nathan Chen <[email protected]> > > > > 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 <[email protected]> > > --- > > 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 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. Pavel
