Re: [PATCH v2 8/9] vfio: Check compatibility of CPU and IOMMU address space width

["Cédric Le Goater" <clg@redhat.com>]

Hello Gerd,

On 1/31/25 14:23, Gerd Hoffmann wrote:
> On Fri, Jan 31, 2025 at 01:42:31PM +0100, Cédric Le Goater wrote:
>> + Gerd for insights regarding vIOMMU support in edk2.
>>
>>>> +static bool vfio_device_check_address_space(VFIODevice *vbasedev, Error **errp)
>>>> +{
>>>> +    uint32_t cpu_aw_bits = cpu_get_phys_bits(first_cpu);
>>>> +    uint32_t iommu_aw_bits = vfio_device_get_aw_bits(vbasedev);
>>>> +
>>>> +    if (cpu_aw_bits && cpu_aw_bits > iommu_aw_bits) {
>>>
>>> Should we be testing the 64-bit MMIO window and maximum RAM GPA rather
>>> than the vCPU physical address width?
> 
> Placing the 64-bit  mmio window is done by the guest firmware,
> so this isn't something qemu can check before boot.
> 
>>> However, we've decided to do exactly that for the 64-bit MMIO window.
>>> It's not that the vCPU width being greater than the IOMMU width is a
>>> fundamental problem, it's that we've chosen a 64-bit MMIO policy that
>>> makes this become a problem and QEMU only has a convenient mechanism to
>>> check the host IOMMU width when a vfio device is present.  Arguably,
>>> when a vIOMMU is present guest firmware should be enlightened to
>>> understand the address width of that vIOMMU when placing the 64-bit
>>> MMIO window.  I'd say the failure to do so is a current firmware bug.
> 
> edk2 has no iommu driver ...
> 
> Is there some simple way to figure what the iommu width is (inside the
> guest)?

When using VFIO, vfio_device_get_aw_bits() will return the IOMMU
address space width. There are checks when using a vIOMMU that
the host and vIOMMU address space are compatible. vIOMMU should
be smaller.

> Note that there is a 'guest-phys-bits' property for x86 CPUs, which is a
> hint for the guest what the usable address width is.  It was added
> because there are cases where the guest simply can't figure that it is
> not possible to use the full physical address space of the cpu.  There
> are some non-obvious limitations around 5-level paging.  Intel has some
> CPUs with phys-bits > 48 but only 4-level EPT for example.
> 
> So one option to handle this is to make sure guest-phys-bits is not
> larger than the iommu width.

Yes. This is what I am trying to do.

Patch [1] returns X86_CPU(cs)->phys_bits. I was not sure which *phys*
property to use. If you think this is incorrect and not returning the
right information, I will change the proposal with guest-phys-bits.

Thanks,

C.

[1] https://lore.kernel.org/qemu-devel/20250130134346.1754143-8-clg@redhat.com/