On Fri, 11 Oct 2013 14:27:12 +0200 Gerd Hoffmann <kra...@redhat.com> wrote:
> On Fr, 2013-10-11 at 13:20 +0200, Igor Mammedov wrote: > > On Thu, 10 Oct 2013 14:54:29 +0200 > > Gerd Hoffmann <kra...@redhat.com> 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 > >
