From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] QEMU - provide e820 reserve through qemu_cfg Date: Mon, 25 Jan 2010 14:14:31 -0600 Message-ID: <4B5DFBA7.9080100@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , QEMU Developers , KVM General , Kevin O'Connor , Avi Kivity , Anthony Liguori To: Alexander Graf Return-path: Received: from mail-ew0-f219.google.com ([209.85.219.219]:40600 "EHLO mail-ew0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207Ab0AYUOi (ORCPT ); Mon, 25 Jan 2010 15:14:38 -0500 Received: by ewy19 with SMTP id 19so152508ewy.21 for ; Mon, 25 Jan 2010 12:14:37 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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