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 <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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.
Michal
