From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH] QEMU - provide e820 reserve through qemu_cfg Date: Mon, 25 Jan 2010 21:04:22 +0100 Message-ID: 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 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: QEMU Developers , KVM General , "Kevin O'Connor" , Avi Kivity , Anthony Liguori To: Jes Sorensen Return-path: Received: from cantor.suse.de ([195.135.220.2]:38972 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468Ab0AYUE2 convert rfc822-to-8bit (ORCPT ); Mon, 25 Jan 2010 15:04:28 -0500 In-Reply-To: <4B5DD8DE.7050100@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZVAq-0001hs-ML for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:04:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZVAl-0001gU-Dj for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:04:35 -0500 Received: from [199.232.76.173] (port=37537 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZVAk-0001gR-8v for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:04:30 -0500 Received: from cantor.suse.de ([195.135.220.2]:38975 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZVAk-0004r2-53 for qemu-devel@nongnu.org; Mon, 25 Jan 2010 15:04:30 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <4B5DD8DE.7050100@redhat.com> Date: Mon, 25 Jan 2010 21:04:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> 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: Jes Sorensen Cc: Anthony Liguori , Kevin O'Connor , QEMU Developers , KVM General , Avi Kivity 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. >>>=20 >>> I am fine with having QEMU build the e820 tables completely if there = is >>> a consensus to take that path. >>=20 >> I agree. We better get this right :-). I don't want to maintain 5 >> versions of an 380 fw_cfg interface. >=20 > 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? Alex=