On Thu, Jan 22, 2026 at 12:00:55 +0100, Michal Prívozník wrote:
On 1/21/26 18:04, Peter Krempa wrote:
On Wed, Jan 21, 2026 at 17:27:20 +0100, Michal Privoznik via Devel wrote:
From: Michal Privoznik <mprivozn@redhat.com>
In PCI assignment scenario the virtio-iommu needs to know the guest page size also known as granule. Expose it as an attribute
^^^^
to the <driver/> element of a virtio-iommu.
This is possibly interesting only for aarch64 since it supports virtio-iommu and also supports running guests with different page size than the host.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- docs/formatdomain.rst | 7 +++++ src/conf/domain_conf.c | 30 ++++++++++++++++++- src/conf/domain_conf.h | 13 ++++++++ src/conf/domain_validate.c | 9 ++++-- src/conf/schemas/domaincommon.rng | 11 +++++++ src/libvirt_private.syms | 2 ++ .../virtio-iommu-aarch64.aarch64-latest.xml | 2 +- .../qemuxmlconfdata/virtio-iommu-aarch64.xml | 2 +- 8 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 4b34a8a963..1dfe3915b5 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -9264,6 +9264,13 @@ Example: The ``pciBus`` attribute notes the index of the controller that an IOMMU device is attached to. (QEMU/KVM and ``smmuv3`` model only)
+ ``granule`` + This allows to choose which granule will be used by default by the
Put the above explanation also here.
+ virtio-iommu and is useful when running guests with different page size + than the host. Accepted values are: ``4K``, ``8K``, ``16K``, ``64K`` and
Since this is supposed to mean page size you should use the lowercase 'k' for kilo? Or perhaps directly kiB ?
I wondered about that. But let's enumerate our possibilities.
1) <driver granule='4k'/> 2) <driver granule='4096'/> 3) <driver granule='4' unit='KiB'/> 4) <driver granule='4' granuleUnit='KiB'/> 5) <driver> <granule unit='KiB'>4</granule> </driver>
Problem with 3 is that 'unit' is not specific enough and if we ever want to invent a new attribute that'd accept units, we're cooked. 4) is more descriptive but I'm not a big fan of it either. That leaves us with 2) where the unit is bytes, or 5) which is the most future proof IMO.
I'm not a fan of the value being content and unit being attribute. You also need to be able to use the 'host' mode which doesn't represent well as a number. Internally we can do 'host' as an extra bool, but also we don't really need to be able (for now) represent the full scale of numbers, but that can be handled by validation. I'd consider: <driver> <granule mode='host'/> or <granule size='4' unit='KiB'/> </driver>