From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKgGl-00085j-2h for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:53:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKgGg-00082u-Jj for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:53:26 -0500 Received: from [199.232.76.173] (port=34875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKgGg-00082n-9J for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:53:22 -0500 Received: from mail.gmx.net ([213.165.64.20]:58866) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NKgGf-0001AH-P8 for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:53:22 -0500 Message-ID: <4E3D53DBD9F24DC689E42B2E79AF735A@FSCPC> From: "Sebastian Herbszt" References: <20091214203603.GJ6150@redhat.com> <4B26A3B2.2030006@codemonkey.ws> <20091214205141.GC6398@redhat.com> <4B26F678.4010603@codemonkey.ws> <4B27541F.9020603@redhat.com> <4B27E1C2.5090506@codemonkey.ws> <20091215211900.GG26712@redhat.com> <4B280374.5010604@codemonkey.ws> <20091215215244.GI26712@redhat.com> <4B28064A.1070501@codemonkey.ws> <20091215215942.GJ26712@redhat.com> <4B280D20.5050203@codemonkey.ws> In-Reply-To: <4B280D20.5050203@codemonkey.ws> Subject: Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?) Date: Tue, 15 Dec 2009 23:51:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, glommer@redhat.com, Kevin O'Connor , Gerd Hoffmann , Alexander Graf Anthony Liguori wrote: > Michael S. Tsirkin wrote: >>> I think it's stable-0.12 material because it's badly broken right now >>> >> >> I thought the rule was no guest visible changes in stable series? >> > > Yeah, good point, so we need to figure out something for 0.12.0. > > Sebastian's suggestion of loading roms from 0xc0000 first and then from > PCI devices is a good one, but I think the problem with that is that the > roms don't necessarily have to be contiguous in that space. For > instance, the lower bios portions are technically in the rom area which > leaves a big gap in the middle. I don't think i get your objection - mind to explain it a little bit? My suggestion was like this: PCI pc and -option-rom rom1.bin -option-rom rom2.bin Qemu will map rom1.bin to PC_ROM_MIN_OPTION (0xc8000) and map rom2.bin to 0xd0000. Either qemu will map vga bios to PC_ROM_MIN_VGA (0xc0000) or SeaBIOS will map it there (with pci 3.0 it could map it somewhere else, but i doubt thats a good idea). In case the vga bios size is below 0x8000, some rom space is lost. SeaBIOS will scan the option rom space starting at PC_ROM_MIN_OPTION and adjust its RomEnd in case a rom is found. Then it will start the pci scan and map pci option roms after RomEnd. - Sebastian