From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKYGL-0007xy-IN for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:20:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKYGG-0007x0-3V for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:20:28 -0500 Received: from [199.232.76.173] (port=55064 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKYGF-0007wp-Nq for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:20:23 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:40622) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKYGF-0000JS-NY for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:20:23 -0500 Received: by ywh1 with SMTP id 1so3847720ywh.18 for ; Tue, 15 Dec 2009 06:20:22 -0800 (PST) Message-ID: <4B279B24.1090004@codemonkey.ws> Date: Tue, 15 Dec 2009 08:20:20 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?) References: <4B26931E.4000101@codemonkey.ws> <20091214194210.GB6150@redhat.com> <4B269933.3010906@codemonkey.ws> <20091214202019.GF6150@redhat.com> <4B26A0DE.5000304@redhat.com> <20091214203428.GI6150@redhat.com> <20091214203603.GJ6150@redhat.com> <4B26A3B2.2030006@codemonkey.ws> <20091214205141.GC6398@redhat.com> <4B26F678.4010603@codemonkey.ws> <20091215043454.GD22611@morn.localdomain> <4B278BE9.3010900@codemonkey.ws> In-Reply-To: <4B278BE9.3010900@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, qemu-devel@nongnu.org Anthony Liguori wrote: > > The bios gets mapped in 0xe0000 .. 0x100000 so if SeaBIOS fills the > 0xc0000-0xf0000 space it will write over half of the bios. I'm a little confused by this. SeaBIOS seems to assume that it only has to deal with the 0xf0000 .. 0x100000 space as the bios which is certainly true (i don't think there's anything special about the 0xe0000 .. 0xf0000 region). I'm not sure why we load the 128K worth of bios instead of just loading 64K. Regards, Anthony Liguori > Regards, > > Anthony Liguori