From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7qMc-0001RG-Fj
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:02:26 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7qMX-0001Pa-8A
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:02:25 -0500
Received: from [199.232.76.173] (port=57005 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7qMX-0001PU-1H
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:02:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:50470)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N7qMW-0005W2-2q
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:02:20 -0500
Message-ID: <4AF96457.1070701@redhat.com>
Date: Tue, 10 Nov 2009 15:02:15 +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>
	<20091109184157.GA12566@mothafucka.localdomain>
In-Reply-To: <20091109184157.GA12566@mothafucka.localdomain>
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: Glauber Costa <glommer@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Gleb Natapov <gleb@redhat.com>, Alexander Graf <agraf@suse.de>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Kevin O'Connor <kevin@koconnor.net>, beth kon <eak@us.ibm.com>

On 11/09/2009 08:41 PM, Glauber Costa 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). We just need to make sure it doesn't overwrite the BIOS
>> itself, as data in there might have been changed already.
>>      
> Can't we put these data somewhere else, and let our int19 handler copy
> it to the right location?
>    

Anywhere you put it the bios has a right to trample.  Of course our bios 
(and its maintainer) are cooperative, but there's not reason to impose 
on that if we can do the right thing and load the data at the right moment.

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