From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NjTjE-00023A-TN for qemu-devel@nongnu.org; Mon, 22 Feb 2010 03:33:20 -0500 Received: from [199.232.76.173] (port=54530 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjTjE-000232-F4 for qemu-devel@nongnu.org; Mon, 22 Feb 2010 03:33:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NjTjD-00065k-1W for qemu-devel@nongnu.org; Mon, 22 Feb 2010 03:33:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4837) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NjTjC-00065g-MX for qemu-devel@nongnu.org; Mon, 22 Feb 2010 03:33:18 -0500 Date: Mon, 22 Feb 2010 10:33:12 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch Message-ID: <20100222083312.GQ14767@redhat.com> References: <4B79857A.1030808@redhat.com> <4B7EFC74.10209@codemonkey.ws> <4B817117.1020700@redhat.com> <20100221191351.GA30303@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100221191351.GA30303@morn.localdomain> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Jes Sorensen , QEMU Developers , Stefano Stabellini 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.