From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NLD2y-0008OA-Nt for qemu-devel@nongnu.org; Thu, 17 Dec 2009 04:53:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NLD2u-0008In-0Z for qemu-devel@nongnu.org; Thu, 17 Dec 2009 04:53:24 -0500 Received: from [199.232.76.173] (port=53806 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NLD2t-0008Ie-Sa for qemu-devel@nongnu.org; Thu, 17 Dec 2009 04:53:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61176) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NLD2t-0005nD-5n for qemu-devel@nongnu.org; Thu, 17 Dec 2009 04:53:19 -0500 Date: Thu, 17 Dec 2009 11:50:28 +0200 From: "Michael S. Tsirkin" Subject: Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?) Message-ID: <20091217095028.GC4905@redhat.com> References: <4B26F678.4010603@codemonkey.ws> <4B27541F.9020603@redhat.com> <4B276197.1080606@redhat.com> <4B27E518.7060300@codemonkey.ws> <20091215211715.GF26712@redhat.com> <4B28026E.4060100@codemonkey.ws> <20091216045725.GC12410@morn.localdomain> <4B290951.20505@redhat.com> <20091217012434.GB11279@morn.localdomain> <4B29FDC9.4080109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B29FDC9.4080109@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Chris Wright , glommer@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Sebastian Herbszt On Thu, Dec 17, 2009 at 10:45:45AM +0100, Gerd Hoffmann wrote: > On 12/17/09 02:24, Kevin O'Connor wrote: >> On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote: >> The current "CBFS" mechanism looks for named "files" of the following >> form: >> >> - pciVVVV,DDDD.rom - a rom associated with a PCI device with the given >> vendor and device id. > > Might be useful for backward compatibility with older qemu versions as > adding a rom bar to the pci devices is a guest-visible change in pci > config space. > >> - vgaroms/* - any "file" starting with the "vgaroms/" prefix is >> treated as a vga option rom not associated with any specific pci >> device. > > obvious place for vgabios. > >> - genroms/* - any "file" starting with the "genroms/" prefix is >> treated as a generic option rom not associated with any specific pci >> device. > > and this for the non-pci roms like extboot & > >> Associating a name to the fw_cfg entries and using the naming >> convention above would allow SeaBIOS to reuse its existing code. > > Ok. > >>> I'd tend to have one fw_cfg entry which returns structed data, like this: >>> >>> struct fw_files { >>> u32 filecount; >>> struct fw_file { >>> u32 type; /* vga, option, other? */ >>> u32 size; /* file size */ >>> u32 select; /* write this to 0x510 to read it */ >>> u32 reserved; /* you never know ;) */ >>> char name[16]; /* maybe: filename */ Can't name simply be null terminated? >>> }; >>> }; >>> >>> What do you think? >> >> It works for me. The name would need to be larger (64 bytes?). > > I'd size name so it pads the struct to 32 or 64 bytes total. 32bit > size, 16bit select, 16bit reserved, leaves 24 bytes for the name with 32 > bytes. Hmm, better to go for a 64 byte struct, leaving 56 bytes for the > name, which should be enougth. > > I'll have patches ready later today. > > cheers, > Gerd -- MST