[ipxe-devel] One ROM, multiple PCI IDs

[Stefan Hajnoczi]

On Sat, Jul 31, 2010 at 7:07 PM, Joshua Oreman <oremanj at rwcr.net> wrote:
> On Sat, Jul 31, 2010 at 3:08 AM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
>> Josh: I have CCed you explicitly because I think you had ideas on this
>> some time ago.
>>
>> The question of multiple PCI IDs for a single gPXE ROM came up
>> recently on IRC.  It can be useful to have a single gPXE ROM file that
>> works on multiple PCI devices that have different IDs.
>>
>> I reviewed the PnP, BBS, and PCI 3.0 Firmware specifications to check
>> whether it is possible or not.  The constraints end up making
>> general-purpose multiple PCI ID ROMs infeasible.  I think it is not
>> worth pursuing this unless these ROMs can be widely used.
>
> Have we gotten a lot of requests for this feature? I'm under the
> impression that most cases of "I want to make a single ROM and flash
> it on every machine in my cluster" involve fairly homogeneous setups.

The question was about making one gPXE ROM that VirtualBox could use
regardless of the emulated NIC type (pcnet32 or e1000).

>
>> The approaches I found are:
>> 1. PCI 3.0 device ID list.  The PCI 3.0 Data Structure includes a
>> Device List pointer allowing a ROM to advertise support for additional
>> *device* IDs.  Two limitations here: only additional device IDs may be
>> used, not vendor IDs, and the BIOS needs to have PCI 3.0 Firmware
>> support.
>
> This could work well in the "fairly homogeneous" case I mentioned. We
> could extend the build system such that "make bin/8086.rom" would make
> a ROM with support for all the e1000 variants (though that particular
> case would also pull in e1000e and e1000igb and generally be
> infeasibly large).
>
>> 2. Using multiple ROM headers.  This means providing multiple
>> expansion ROM headers within the ROM so the BIOS can pick an
>> applicable one.  However, each header must start on a 512-byte
>> boundary and I don't see a reasonable way to share the compressed gPXE
>> image between multiple ROM headers.  There will not be enough space to
>> accommodate multiple (duplicate) images, and the alternative is a more
>> complex loader that tries to fetch gPXE as a second stage payload from
>> the PCI expansion ROM (which is known to be tricky).
>
> Using the .mrom facility that Michael contributed, this would be
> feasible for small sets of ROMs from a size perspective.
>
>> Thoughts?
>
> I actually haven't thought about this use case that much. I think both
> possibilities are tractable, but like you suggest, probably not worth
> the effort unless someone would use them extensively. A much simpler
> alternative that would cover many of the same use cases would be to
> restore the functionality that used to be in modrom.pl of "rebranding"
> the ROM device:vendor IDs post-build.
>
> -- Josh
>