On Wed, Mar 11, 2026 at 10:21:08AM -0700, Nathan Chen wrote: > > > On 2/27/2026 10:25 AM, Nathan Chen wrote: > > > > > > On 2/25/2026 5:07 AM, Pavel Hrdina wrote: > > > > On 2/23/2026 12:21 PM, Pavel Hrdina wrote: > > > > > > + ``ril`` > > > > > > + The ``ril`` attribute with possible values ``on`` > > > > > > and ``off`` can be used > > > > > > + to report whether Range Invalidation for > > > > > > smmuv3Dev IOMMU devices with > > > > > > + ``accel`` set to ``on`` is compatible with host SMMUv3 > > > > > > support. > > > > > > + (QEMU/KVM and ``smmuv3`` model only) > > > > > Current default in QEMU is `on` but if `accel` is enabled it > > > > > has to match > > > > > what is supported by host SMMUv3 and QEMU errors out if incorrect > > > > > value > > > > > is used. > > > > > > > > > > I wonder why QEMU cannot figure out the default value if nothing is > > > > > specified? This way when acceleration is enabled and host > > > > > SMMUv3 doesn't > > > > > support RIL user needs to manually set this option as well. > > > > > > > > > > > + > > > > > > + ``ssidSize`` > > > > > > + The ``ssidSize`` attribute sets the number of > > > > > > bits used to represent > > > > > > + SubstreamIDs. A value of N allows SSIDs in the > > > > > > range [0 .. 2^N - 1]. > > > > > > + The valid range is 0-20, and a value greater than > > > > > > 0 is required for > > > > > > + enabling PASID support, as doing so advertises > > > > > > PASID capability to > > > > > > + the vIOMMU. (QEMU/KVM and ``smmuv3`` model only) > > > > > By default this is disabled in QEMU and can be used only with accel > > > > > enabled. If user picks 20 it can be still rejected by QEMU if the host > > > > > doesn't support that size. > > > > > > > > > > Is this necessary to be enabled and what is reasonable default user > > > > > should use? > > > > > > > > > > > + ``oas`` > > > > > > + The ``oas`` attribute sets the output address > > > > > > size in units of bits. > > > > > > + (QEMU/KVM and ``smmuv3`` model only) > > > > > Currently supported values in QEMU are 44 and 48 > > > > > bits. QEMU defaults to 44, if accel is off it has to be 44, if accel > > > > > is on it can be 48. In addition QEMU also errors out if user sets OAS > > > > > greater than what is supported by host. > > > > > > > > > > How is user supposed to figure this out and why QEMU cannot pick > > > > > reasonable default? > > > > > > > > > > > The ``virtio`` IOMMU devices can further have > > > > > > ``address`` element as described > > > > > > in `Device addresses`_ (address has to by type of ``pci``). > > > > > For all these options we should store the default value in XML if user > > > > > doesn't provide it to make sure that existing VMs will not change if > > > > > QEMU changes its defaults. > > > > There has been some discussion on supporting an 'auto' value for these > > > > properties in the QEMU layer [0]. I think it would make sense to refresh > > > > this series with support for the 'auto' value, deriving these properties > > > > from host IOMMU capabilities so Libvirt users do not have to > > > > introspect host > > > > settings. > > > > > > > > Would you suggest consolidating this implementation into a > > > > single 'accel' > > > > driver attribute, and then setting the values for ril, ssidsize, > > > > and oas to > > > > 'auto' in the qemu command line when accel=on? Or still supporting > > > > user-defined values for ril, ssidsize, and oas but also > > > > supporting 'auto'? > > > That depends if it's expected from users to change these values and why > > > would they change them. > > > > > > For example ssidSize set to 0 disables PASID support, is it expected > > > from users to disable this feature or set ssidsize to any specific > > > value? If yes we need to have this attribute in XML but we should also > > > use reasonable default that is supported by current host. > > > > > > RIL currently needs to be disabled but my guess is in the future it will > > > be possible to have it enabled. > > > > > > OAS currently can be only 44 when accel is disabled, but can be 48 if > > > accel is enabled, is it expected from users to use 44 with accel > > > enabled? And in the future will there be any other value supported and > > > possible used as default? > > > > > > Same for ATS, is it expected from users to disable it when accel is > > > enabled? > > > > > > It also depends if migration of running VM with accelerated SMMUv3 > > > is/will be supported. If yes we will need to have the current values in > > > XML to make sure migration to different host with possibly different > > > supported values will be rejected as otherwise the VM device would > > > change. > > > > > > I would say it should be enough to set only `accel='on'` and the rest > > > should be filled in using reasonable defaults unless it is explicitly > > > specified in XML and every default should be stored in the XML. > > > > > > That should be ideally done when the VM is defined, so all values are > > > stored in config XML, otherwise we would have to read the values from > > > running QEMU process every time the VM is started. > > > > > > This would require QEMU to report the default values based on what host > > > and QEMU supports via QAPI so libvirt can ask QEMU when defining new VM > > > or libvirt would have to figure this out probing host directly. > > > This means libvirt doesn't need adding `auto` as possible value for > > > these properties. > > > > > > We could add `mode='host'` like it was done for virtio-iommu granule but > > > IMO that should translate to `accel=host` on QEMU command line and QEMU > > > should error out if any other property is set. > > > > I discussed the live migration use case with Shameer - it is currently > > not supported but QEMU should be checking if the resolved auto values > > match between source and target when live migration support is > > implemented, and prevent the migration if there is a mismatch. With that > > in mind, it seems like adding support for ril='auto',ats='auto', etc. > > without resolving the values in the XML should be OK to implement, but > > what are your thoughts? > > > > The issue with filling in reasonable defaults at libvirt XML definition > > time is that a device must be attached to iommufd context before these > > host SMMU properties can be queried. That means we would have to detect > > a device that's bound to a vSMMU in the XML, ensure it's not in use by > > other processes, and bind it to vfio-pci, and attach it to iommufd > > context at libvirt XML define time before a VM is actually booted. > > Another alternative which doesn't seem ideal either is to query the host > > SMMU properties after VM boots, then re-write the libvirt XML values set > > to 'auto' once the VM is booted. > > I found that the x86 IOMMU intremap property, which is OnOffAuto in QEMU, is > implemented in Libvirt as a virTristateSwitch and accepts only 'on' or 'off' > [0]. When omitted from the Libvirt XML, it is not specified on the qemu > command line and qemu uses the default 'auto' value as a result [1]. Should > we follow something similar for these accel SMMUv3 properties?
Hi Nathan,
Correct, if the desired default behavior is to configure the VM with:
<iommu model='smmuv3'>
<driver pciBus='1' accel='on'/>
</iommu>
in order to use `auto` for remaining attributes we should use
qemuOnOffAuto() as I did here for CentOS [1].
For ssidsize and oas we will need to use -1 to indicate it was not set
and when building QEMU cmd we can use:
"k:ssidsize", iommu->ssid_size,
"k:oas", iommu->oas,
You can check documentation for virJSONValueObjectAddVArgs() to see how
each letter works.
Implemented like this will ensure that when XML attribute is missing,
nothing is added to QEMU cmd and qemu will automatically figure out the
values, of any of the attributes are present, they will be added to QEMU
cmd.
[1]
https://gitlab.com/redhat/centos-stream/src/libvirt/-/commit/bbb78985cf3d7891578f6bfef8e5c2d65cb3868f
Pavel
>
> [0]
> https://github.com/libvirt/libvirt/commit/2020e2c6f2656ca1aa9032859ccde76185c37c39
> [1]
> https://github.com/libvirt/libvirt/commit/cefa20b727bd9e0fcaade0704a5e9055d6f32a98
>
> Thanks,
> Nathan
>
signature.asc
Description: PGP signature
