[Top][All Lists]

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

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

From: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
Date: Sun, 21 Feb 2010 14:13:51 -0500
User-agent: Mutt/1.5.20 (2009-08-17)

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?


reply via email to

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