[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] pc: allow raising low memory via max-ram-bel

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v2] pc: allow raising low memory via max-ram-below-4g option
Date: Mon, 11 Jan 2016 09:26:20 +0100

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 <address@hidden> 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.


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]