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.