Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch

[Gleb Natapov <gleb@redhat.com>]

On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote:
> On Sun, Feb 21, 2010 at 06:44:55PM +0100, Jes Sorensen wrote:
> > On 02/19/10 22:02, Anthony Liguori wrote:
> > >I noticed that you use this for the TSS page with EPT but you don't use
> > >this interface for the rest of memory. I'm curious what you think the
> > >right long term split is? If QEMU is not managing the full e820 table,
> > >can we reasonable add entries on our own?
> > 
> > I'd like to have QEMU handle more, I picked the TSS page because we
> > changed the location of that in the past and it was the one that
> > triggered my patch in the first place. Now we have the infrastructure,
> > it will be easier to add more.
> 
> What parts of the memory map do you envision qemu managing?
> 
> On qemu, SeaBIOS manages the map for ram under 1M, creates the map for
> high-memory based on the max memory sizes located in cmos, and it
> manages reserved entries for the acpi/smbios tables.  (It also adds an
> entry for the rom (the last 256K of the 4gig space), which, BTW, would
> be nice to include in your patch.)
> 
> Interestingly, on coreboot, SeaBIOS reads the memory map from coreboot
> and calculates the max memory sizes (the opposite of what it does on
> qemu).  Also, it's coreboot that generates the bios tables - SeaBIOS
> uses the passed in memory map to locate the tables and copy the
> required parts into the f-segment.
> 
> Are you thinking of moving qemu more torwards what coreboot does, or
> did you have a different idea in mind?
> 
We shouldn't compare coreboot with qemu. Qemu is a hardware. Coreboot
is part of a firmware.

--
			Gleb.