From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NKXFQ-00064Z-PC
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 08:15:28 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NKXFM-00063Z-PG
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 08:15:28 -0500
Received: from [199.232.76.173] (port=55894 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NKXFM-00063S-Li
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 08:15:24 -0500
Received: from mail-yx0-f188.google.com ([209.85.210.188]:55742)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NKXFL-0002Ac-TR
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 08:15:24 -0500
Received: by yxe26 with SMTP id 26so3962485yxe.4
	for <qemu-devel@nongnu.org>; Tue, 15 Dec 2009 05:15:23 -0800 (PST)
Message-ID: <4B278BE9.3010900@codemonkey.ws>
Date: Tue, 15 Dec 2009 07:15:21 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
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>
In-Reply-To: <20091215043454.GD22611@morn.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: Kevin O'Connor <kevin@koconnor.net>
Cc: seabios@seabios.org, qemu-devel@nongnu.org

Kevin O'Connor wrote:
> On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote:
>   
>> Okay, I think I've figured out how this is supposed to work.  With these  
>> two patches to SeaBIOS and the patch to qemu, I can run:
>>     
>
> I'm not sure why "Do not guard qemu shadow ram work around in
> CONFIG_OPTIONROMS_DEPLOYED" patch is needed.  The code today is:
>
>         if (CONFIG_OPTIONROMS_DEPLOYED) {
>             int reg = pci_config_readb(bdf, 0x5a + i);
>             if ((reg & 0x11) != 0x11) {
>                 // Need to copy optionroms to work around qemu implementation
>                 void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
>                 memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
>                 pci_config_writeb(bdf, 0x5a + i, 0x33);
>                 memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
>                 clear = 1;
>             } else {
>                 pci_config_writeb(bdf, 0x5a + i, 0x33);
>             }
>         } else {
>             pci_config_writeb(bdf, 0x5a + i, 0x33);
>         }
>
> So, in the non CONFIG_OPTIONROMS_DEPLOYED case, SeaBIOS will just do
> the write enable call (pci_config_writeb(bdf, 0x5a + i, 0x33)).  The
> CONFIG_OPTIONROMS_DEPLOYED case should just be to copy the roms qemu
> has deployed.  If SeaBIOS is filling in the 0xc0000-0xf0000 space, it
> shouldn't matter if the contents of that space is lost during the
> write enable.
>   

The bios gets mapped in 0xe0000 .. 0x100000 so if SeaBIOS fills the 
0xc0000-0xf0000 space it will write over half of the bios.

Regards,

Anthony Liguori