Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture

[Guilherme Piccoli]

Thanks a lot for all the responses here! Very constructive discussion =)
Comments inline!

On Wed, Jun 17, 2020 at 10:22 AM Laszlo Ersek <lersek@redhat.com> wrote:
> [...]
> If QEMU can provide a *reliable* GPA width, in some info channel (CPUID
> or even fw_cfg), then the above calculation could be reversed in OVMF.
> We could take the width as a given (-> produce the CPU HOB directly),
> plus calculate the *remaining* address space between the GPA space size
> given by the width, and the end of the memory hotplug area end. If the
> "remaining size" were negative, then obviously QEMU would have been
> misconfigured, so we'd halt the boot. Otherwise, the remaining area
> could be used as PCI64 MMIO aperture...

That was *exactly* the way I was considering, but without the right
terminology due to my lack of experience in this topic heheh
Thanks for the great summary of the idea! I was considering fw_cfg,
but can be CPUID too, let me know what is the "trendy" way to do that.
So, the only problem with that refactor you're proposing is the
retrocompatibility with qemu versions, as I can anticipate cases in
which newer OVMF runs with older qemu, which does not provide such
trustworth physbits info. So, the code may be a bit complex, it'll
need to take into account this case (probably we could just rely on
the physbits "detected" by OVMF in such case, limiting PCI64 aperture
to the current 36-bits, right?).


> (PEI memory footprint of DXE page tables be darned).
LOL

Cheers,
Guilherme