Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)

[Kevin O'Connor]

On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote:
>> Right now, qemu cfg uses two ports - a file select port (0x510) and a
>> data port (0x511).  Perhaps two new ports could be added - a file name
>> port (0x0512) and a file length port (0x513).
>>
>> Basically, if there is some way for SeaBIOS to walk a list of "files"
>> in the "qemu cfg" space, then it should be straight forward to enhance
>> the existing code in seabios to extract and deploy roms in addition to
>> those found in the PCI bar.
>
> What information does seabios need?
>
> It probably needs to know whenever the rom in question is the vga bios  
> or an option rom.
>
> It probably also wants to get the vga bios first I assume?

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.

- vgaroms/* - any "file" starting with the "vgaroms/" prefix is
  treated as a vga option rom not associated with any specific pci
  device.

- genroms/* - any "file" starting with the "genroms/" prefix is
  treated as a generic option rom not associated with any specific pci
  device.

The deployment order is: find the PCI vga device and look for a
corresponding "pciVVVV,DDDD.rom" file or a PCI bar for it, deploy any
"vgaroms/*" roms, iterate through all non-vga PCI devices and deploy
their corresponding "pciVVVV,DDDD.rom" or PCI bar roms, deploy any
"genroms/*" roms.

When SeaBIOS deploys a rom that is associated with a specific PCI
device (either "pciVVVV,DDDD.rom" or PCI bar), it passes the PCI
location as a parameter to the rom (as is required in the PCI firmware
spec).  Roms not associated with a device (genroms/*, vgaroms/*, and
when CONFIG_OPTIONROMS_DEPLOYED) don't pass in the PCI id, so they
have a slightly different calling convention.

> Is a (file) name needed?

Associating a name to the fw_cfg entries and using the naming
convention above would allow SeaBIOS to reuse its existing code.  It
seems to me that both coreboot and qemu are trying to solve the same
problem, so using the same mechanism seems advantageous.

BTW, my preference would be to assign a name to all fw_cfg entries;
even the existing ones.

> Would seabios load the option roms one by one or all in one go?

One by one - so it can satisfy the requirement of passing the PCI
location as a parameter to roms that may need that while still
handling roms not associated with a device (eg, kvm's vbios, the
-kernel rom, etc.).

> 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 */
>   };
> };
>
> What do you think?

It works for me.  The name would need to be larger (64 bytes?).  The
current scheme essentially encodes 'type' into the name, so it
wouldn't be needed.

-Kevin