From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N4y3v-0005nZ-2T
	for qemu-devel@nongnu.org; Mon, 02 Nov 2009 09:39:15 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N4y3q-0005j6-IA
	for qemu-devel@nongnu.org; Mon, 02 Nov 2009 09:39:14 -0500
Received: from [199.232.76.173] (port=36610 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N4y3q-0005iz-ES
	for qemu-devel@nongnu.org; Mon, 02 Nov 2009 09:39:10 -0500
Received: from mx1.redhat.com ([209.132.183.28]:50999)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N4y3p-0005Va-Ux
	for qemu-devel@nongnu.org; Mon, 02 Nov 2009 09:39:10 -0500
Message-ID: <4AEEEF08.9070900@redhat.com>
Date: Mon, 02 Nov 2009 16:39:04 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE
References: <4AEAFE39.1030302@us.ibm.com> <4AEED5EC.8000406@suse.de>
	<4AEED9D8.2020307@redhat.com> <4AEEDB75.3090100@suse.de>
	<4AEEDF86.7080009@redhat.com>
	<20091102135107.GA9856@morn.localdomain>
	<4AEEE4F8.1020409@redhat.com> <4AEEE775.2030507@suse.de>
In-Reply-To: <4AEEE775.2030507@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>, Kevin O'Connor <kevin@koconnor.net>, beth kon <eak@us.ibm.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Gleb Natapov <gleb@redhat.com>

On 11/02/2009 04:06 PM, Alexander Graf wrote:
> pc.c:
>      } else {
>          /* High and recent kernel */
>          real_addr    = 0x10000;
>          cmdline_addr = 0x20000;
>          prot_addr    = 0x100000;
>      }
>
> If I'm not totally mistaken, 0x10000 is<  1MB :-).
>
> So yes, I think there should be a fw-conf interface that tells qemu to
> reload all volatile option rom regions (which it keeps track of for
> reset anyway).

Not reload, load.

> We just need to make sure it doesn't overwrite the BIOS
> itself, as data in there might have been changed already.
>    

Well, the bios could tell qemu where to put the kernel using the same 
interface.

-- 
error compiling committee.c: too many arguments to function