On 01/11/16 09:26, Gerd Hoffmann wrote:
> On Fr, 2016-01-08 at 19:32 +0100, Laszlo Ersek wrote:
>> On 01/08/16 18:45, Igor Mammedov wrote:
>>> On Fri,  8 Jan 2016 13:58:03 +0100
>>> Gerd Hoffmann <kra...@redhat.com> wrote:
>>>
>>>> This patch extends the functionality of the max-ram-below-4g option
>>>> to also allow increasing lowmem.  Use case: Give as much memory as
>>>> possible to legacy non-PAE guests.
>>>>
>>>> While being at it also rework the lowmem calculation logic and add a
>>>> longish comment describing how it works and what the compatibility
>>>> constrains are.
>>> CCing Laszlo as it might affect OVMF
>>
>> Thanks a lot for the CC, Igor!
>>
>> So I have to investigate this separately for i440fx and Q35.
>>
>> (1) For i440fx, OVMF determines the base of the 32-bit PCI hole like this:
>>
>>       PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
>>
>> where TopOfLowRam is calculated from the CMOS registers 0x34 and 0x35.
>>
>> *If* QEMU is still sticking with the idea of git commit ddaaefb4dd, that
>> is, the 32-bit PCI hole still starts immediately after the end of low
>> RAM, then this change should be fine for i440fx.
> 
> Good.
> 
>> Gerd, can you confirm that this new logic for the lowmem/highmem split
>> doesn't affect the above?
>>
>> In other words, as long as there is no "void" left between the top of
>> low RAM and the base of the PCI hole, it doesn't matter where exactly
>> the split is.
> 
> Yes, the logic is the same as before.  Anything above ram is pci i/o.
> 
>> (2) For Q35, the OVMF code is different:
> 
> The patch doesn't change q35 behavior.

Thanks for confirming!

Acked-by: Laszlo Ersek <ler...@redhat.com>


Reply via email to