From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: [PATCH] QEMU - provide e820 reserve through qemu_cfg Date: Mon, 25 Jan 2010 18:46:06 +0100 Message-ID: <4B5DD8DE.7050100@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: QEMU Developers , KVM General , "Kevin O'Connor" , Avi Kivity , Anthony Liguori To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50039 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754477Ab0AYRqR (ORCPT ); Mon, 25 Jan 2010 12:46:17 -0500 In-Reply-To: <04C75D06-9153-410E-8D91-474F2A92D265@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. What do you think? Cheers, Jes