From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKf8p-0007G7-5I for qemu-devel@nongnu.org; Tue, 15 Dec 2009 16:41:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKf8k-00079N-Bc for qemu-devel@nongnu.org; Tue, 15 Dec 2009 16:41:10 -0500 Received: from [199.232.76.173] (port=38860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKf8k-00078t-7H for qemu-devel@nongnu.org; Tue, 15 Dec 2009 16:41:06 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:43227) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKf8k-0004Iw-0E for qemu-devel@nongnu.org; Tue, 15 Dec 2009 16:41:06 -0500 Received: by yxe26 with SMTP id 26so361592yxe.4 for ; Tue, 15 Dec 2009 13:41:05 -0800 (PST) Message-ID: <4B28026E.4060100@codemonkey.ws> Date: Tue, 15 Dec 2009 15:41:02 -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: <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> <4B27541F.9020603@redhat.com> <4B276197.1080606@redhat.com> <4B27E518.7060300@codemonkey.ws> <20091215211715.GF26712@redhat.com> In-Reply-To: <20091215211715.GF26712@redhat.com> 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: "Michael S. Tsirkin" Cc: Chris Wright , glommer@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt Michael S. Tsirkin wrote: > On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote: > >> Gerd Hoffmann wrote: >> >>> -kernel didn't work on a quick test. >>> >> Thinking about how to fix this, we have two options. >> > > Hmm, can you pls explain why it stops working? > Sure. SeaBIOS loads roms in a few ways. If CONFIG_OPTIONROMS_DEPLOYED, then SeaBIOS scans the 0xc0000..0xf0000 region for anything that looks like a rom. This is how Bochs did it and is what qemu supports. This is not how modern systems work though. Modern systems (SeaBIOS with !CONFIG_OPTIONROMS_DEPLOYED), walk the PCI bus and look for any device with a PCI_ROM_ADDRESS that maps a valid option rom. It will map the rom in PCI memory and run it's init function. The rom can use PMM to allocate temporary memory to reorganize itself. During this time, the rom area is writable. The rom will create a stub that's usually pretty small that gets loaded by the BIOS after init into the 0xc0000..0xf0000 region. So when !CONFIG_OPTIONROMS_DEPLOYED, SeaBIOS does look in this region for roms because it maps them all from the actual PCI devices. SeaBIOS can also load roms from up to two fixed physical addresses (when !CONFIG_OPTIONROMS_DEPLOYED) or from a CBFS payload. BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests. In fact, it should Just Work with my patches !CONFIG_OPTIONROMS_DEPLOYED in SeaBIOS. >> Regards, >> >> Anthony Liguori >> >>> cheers, >>> Gerd >>> > > Will be a problem for non-PCI systems? > You mean, non-PCI x86 systems? I think -m isapc is mainly used for dos guests. I don't think it's really useful in combination with -kernel and certainly not for extboot. Regards, Anthony Liguori