From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZW7U-0002c2-RA for qemu-devel@nongnu.org; Mon, 25 Jan 2010 16:05:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZW7P-0002a6-CE for qemu-devel@nongnu.org; Mon, 25 Jan 2010 16:05:11 -0500 Received: from [199.232.76.173] (port=40804 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZW7P-0002a1-6D for qemu-devel@nongnu.org; Mon, 25 Jan 2010 16:05:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17260) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZW7O-0002Se-Dp for qemu-devel@nongnu.org; Mon, 25 Jan 2010 16:05:06 -0500 Message-ID: <4B5E077C.2040602@redhat.com> Date: Mon, 25 Jan 2010 22:05:00 +0100 From: Jes Sorensen MIME-Version: 1.0 References: <4B5DCAF2.3010105@redhat.com> <4B5DCB93.7050007@redhat.com> <4B5DCC53.508@redhat.com> <2CE27313-0F43-4A93-905F-3DF4815BC0B5@suse.de> <4B5DD13F.5060105@redhat.com> <04C75D06-9153-410E-8D91-474F2A92D265@suse.de> <4B5DD8DE.7050100@redhat.com> <4B5DFBA7.9080100@codemonkey.ws> In-Reply-To: <4B5DFBA7.9080100@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] QEMU - provide e820 reserve through qemu_cfg List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , KVM General , Alexander Graf , QEMU Developers , Kevin O'Connor , Avi Kivity On 01/25/10 21:14, Anthony Liguori wrote: > On 01/25/2010 02:04 PM, Alexander Graf wrote: >> Yes, sounds good. Should be fairly extensible then. What about memory >> holes? Do we need to take care of them? > > It would be nice for QEMU to be able to add additional e820 regions that > don't necessarily fit the standard layout model. > > For instance, I've thought a number of times about using a large > reserved region as a shared memory mechanism. > > But we certainly need to allow the BIOS to define the regions it needs > to know about. I think it should be easy to accommodate using the scheme I am suggesting. It would require some basic testing for conflicts in the BIOS, but otherwise it should pretty much allow you to specify any region you want as a reserved block. Only problem is that we don't really have a way to pass back info saying 'you messed up trying to pinch an area that the BIOS wants for itself'. I'll take a look at it. Cheers, Jes