From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NZVKf-0007e3-VM
	for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:14:46 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NZVKZ-0007U8-JT
	for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:14:43 -0500
Received: from [199.232.76.173] (port=40764 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NZVKZ-0007Tm-4z
	for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:14:39 -0500
Received: from mail-fx0-f222.google.com ([209.85.220.222]:64725)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NZVKZ-00061U-5D
	for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:14:39 -0500
Received: by fxm22 with SMTP id 22so8302709fxm.2
	for <qemu-devel@nongnu.org>; Mon, 25 Jan 2010 12:14:37 -0800 (PST)
Message-ID: <4B5DFBA7.9080100@codemonkey.ws>
Date: Mon, 25 Jan 2010 14:14:31 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
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>
	<A4568897-CA56-4F1B-A3C1-DDF4DBB84AF0@suse.de>
In-Reply-To: <A4568897-CA56-4F1B-A3C1-DDF4DBB84AF0@suse.de>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>, KVM General <kvm@vger.kernel.org>, Jes Sorensen <Jes.Sorensen@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>

On 01/25/2010 02:04 PM, Alexander Graf wrote:
> On 25.01.2010, at 18:46, Jes Sorensen wrote:
>
>    
>> On 01/25/10 18:28, Alexander Graf wrote:
>>      
>>>>> That way we'd get 2 entries and the chance to enhance them later on.
>>>>> In fact, it might even make sense to pass the whole table in such a
>>>>> form. That way qemu generates all of the e820 tables and we can
>>>>> declare whatever we want. Just add a type field in the table.
>>>>>            
>>>> I am fine with having QEMU build the e820 tables completely if there is
>>>> a consensus to take that path.
>>>>          
>>> I agree. We better get this right :-). I don't want to maintain 5
>>> versions of an 380 fw_cfg interface.
>>>        
>> Looking at the internals, some of the e820 entries are based on compile
>> time constants for the BIOS, so it will be hard to pass those from
>> QEMU, but we could do it in a way so we pass a number of additional
>> e820 entries. Ie. address, length, and type.
>>      
> 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.

Regards,

Anthony Liguori