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

[Cédric Le Goater]

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] 20250130134346.1754143-8-clg@redhat.com/">https://lore.kernel.org/qemu-devel/20250130134346.1754143-8-clg@redhat.com/