Re: [Qemu-devel] [RfC PATCH] e820: pass high memory too.

[Igor Mammedov]

On Fri, 11 Oct 2013 14:27:12 +0200
Gerd Hoffmann <address@hidden> wrote:

> On Fr, 2013-10-11 at 13:20 +0200, Igor Mammedov wrote:
> > On Thu, 10 Oct 2013 14:54:29 +0200
> > Gerd Hoffmann <address@hidden> wrote:
> > 
> > > We have a fw_cfg entry to pass e820 entries from qemu to the firmware.
> > > Today it's used to pass reservations only.  This patch makes qemu pass
> > > entries for RAM too.
> > > 
> > > This allows to pass RAM sizes larger than 1TB to the firmware and it
> > > will also allow to pass non-contignous memory ramges should we decide
> > > to implement that some day, say for our virtual numa nodes.
> > > 
> > > Obviously this needs some extra care to not break existing firware.
> > > 
> > > SeaBIOS loads the entries and happily adds them without looking at the
> > > type.  Which is problematic for memory below 4g as this will overwrite
> > > reservations added for bios memory etc.  For memory above 4g it works
> > > just fine, seabios will merge the entry derived from cmos with the one
> > > loaded from fw_cfg.
> > It will make amount of available memory in e820 table more than described
> > in smbios and could break MS's SMBIOS HCT test.
> 
> Happens only in case the installed amount of memory is larger than 1TB
> (which is the maximum the cmos can describe).  Such a setup doesn't work
> correctly without the patch anyway, so it isn't a regression IMHO.  And
> with an additional patch on the seabios side we can fix the smbios info
> even for the >1TB case.
True, and it looks better then adding extra CMOS ports.

BTW: what about OVMF and core boot, how would they know that there is more
then 1Tb RAM?

> 
> >  Perhaps related smbios info
> > also should be picked up from QEMU.
> 
> Worth investigating, but lets concentrate on the acpi table merge first.
> 
> cheers,
>   Gerd
> 
>