Thanks a lot for all the responses here! Very constructive discussion =) Comments inline!
On Wed, Jun 17, 2020 at 10:22 AM Laszlo Ersek <ler...@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
