Re: [PATCH v2 2/4] OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB

["Laszlo Ersek" <lersek@redhat.com>]

On 1/12/23 15:03, Gerd Hoffmann wrote:
>   Hi,
> 
>>> I think it should actually simplify things.  All the inconsistencies we
>>> have (as you outlined above) due to the hole punching and edk2
>>> supporting only a single range for 32bit mmio should go away, and we
>>> will have less address space layout differences between q35 and pc.
>>
>> We've tried 0xE000_0000 in the past, in commit 75136b29541b.
>>
>> But had to revert it in commit eb4d62b0779c, due to 0xE000_0000 tickling
>> a bug in QEMU.
>>
>> The bug tickling was actually reported by you :) See
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=1859>.
> 
> Oh.  I totally forgot about that.  The patch from (I think) 2019 which
> added _CRS for the range below the MMCONFIG should have fixed that, and
> with recent qemu everything works fine.
> 
> I suspect we can't easily detect whenever qemu is broken or not.  Hmm.
> 
> Is more than three years being passed enough to just do it
> unconditionally and effectively raise the bar for the minimum
> supported qemu version?

Well, in the other thread ("[PATCH v2] OvmfPkg/PlatformInitLib: catch
QEMU's CPU hotplug reg block regression"), I'm proposing a hard hang for
a QEMU bug that's not been fixed in *any* public release yet, and will
only be fixed in v8 :)

Can you determine the exact QEMU bugfix (commit hash) and the first QEMU
release that included it?

Maybe even build & test that version?

If we determine the minimum functional QEMU version precisely, and it's
like v5 or v6, making it the "official minimum" should be fine.

> 
>> (Well, if you mean to keep the same logic for both i440fx adn q35,
>> that's OK then.)
> 
> Yes, it would be Uc32Base.
> 
> LowMemory and Uc32Base are identical anyway most of the time due to qemu
> preferring gigabyte pages when possible, you need odd memory sizes like
> 1.5 or 2.5 GB to see they actually can be different.
> 

Thanks
Laszlo