Xen devel - Jun 2010 - [PATCH] Fix etherboot option ROM loading

Hi,

The option ROM included in the source tree is built with the default PCI
vendor and device ID''s for the gPXE e1000 driver. Unfortunately these
don''t correspond to the ID''s of the installed NIC. For that
reason the
new and improved OPROM probing routines in hvmloader fail to load any
PXE ROM''s meaning no network boot.

Following patch fixes this in the gPXE build process by specifying the
target based on PCI-ID''s and not on device name. I neglected to include
eb-roms.h in the patch since it''s huge.

I am working on improved fix for this by building a gPXE ROM with
support for both rtl8139 and e1000 and then ignoring PCI ID''s in the
option ROM header from within hvmloader - effectively providing a single
Multi-ROM. This fix is enough to get things working for now though.

Enjoy

Gianni Tedesco


diff -r b622e411eef8 tools/firmware/etherboot/Config
--- a/tools/firmware/etherboot/Config	Thu Jun 24 21:56:03 2010 +0100
+++ b/tools/firmware/etherboot/Config	Mon Jun 28 18:17:32 2010 +0100
@@ -1,5 +1,5 @@
 
-NICS = rtl8139 eepro100
+NICS = rtl8139 8086100e
 
 CFLAGS += -UPXE_DHCP_STRICT
 CFLAGS += -DPXE_DHCP_STRICT
diff -r b622e411eef8 tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Thu Jun 24 21:56:03 2010 +0100
+++ b/tools/firmware/etherboot/Makefile	Mon Jun 28 18:17:32 2010 +0100
@@ -19,7 +19,7 @@
 	cat $^ | ../hvmloader/mkhex etherboot >$@
 
 eb-roms.h: Config
-	$(MAKE) $@.new
+	$(MAKE) NO_WERROR=1 $@.new
 	mv -f $@.new $@
 
 $D/src/arch/i386/Config: $T Config



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28/06/2010 19:07, "Gianni Tedesco"
<gianni.tedesco@citrix.com> wrote:
> The option ROM included in the source tree is built with the default PCI
> vendor and device ID''s for the gPXE e1000 driver. Unfortunately
these
> don''t correspond to the ID''s of the installed NIC.
What is "the installed NIC" in this case? We''re not fixing
for one type of
e1000 but in turn breaking for another that we might care about, are we?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28/06/2010 19:07, "Gianni Tedesco"
<gianni.tedesco@citrix.com> wrote:
> I am working on improved fix for this by building a gPXE ROM with
> support for both rtl8139 and e1000
Which is what we do already, right? Or do we actually end up with two
separate ROMs, one for rtl8139 and one for e1000?

Hm, anyway, presumably internally gpxe has a list of vendor_id:device_id
pairs for each NIC type that it supports? Shouldn''t we just patch it so
that
the entire list gets exposed in the option ROM headers? That seems the
simple straightforward fix, or is it more complex than that?

 -- Keir
> and then ignoring PCI ID''s in the
> option ROM header from within hvmloader - effectively providing a single
> Multi-ROM.
>
> This fix is enough to get things working for now though.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 2010-06-28 at 19:57 +0100, Keir Fraser wrote:
> On 28/06/2010 19:07, "Gianni Tedesco"
<gianni.tedesco@citrix.com> wrote:
> 
> > I am working on improved fix for this by building a gPXE ROM with
> > support for both rtl8139 and e1000
> 
> Which is what we do already, right? Or do we actually end up with two
> separate ROMs, one for rtl8139 and one for e1000?
No there''s two separate ROM''s. When I installed the rtl8139
ROM on an
e1000 machine it didn''t recognize any network devices. That''s
what
prompted me to this patch.

And as for fixing for one kind of e1000 and breaking for other cases we
care about, I''m afraid that the answer is "yes we are." At
least
assuming other qemu''s out there with different PCI ID''s?
> Hm, anyway, presumably internally gpxe has a list of vendor_id:device_id
> pairs for each NIC type that it supports? Shouldn''t we just patch
it so that
> the entire list gets exposed in the option ROM headers? That seems the
> simple straightforward fix, or is it more complex than that?
Yeah, I mean, if we load a ROM for e1000, then all types of e1000 will
work but the problem is that I''m not sure how we can get a list in to
the ROM headers. The spec was designed for loading a ROM from a specific
card. If we simply ignore the PCI ID''s in the ROM header and load the
first blob then we may end up loading rtl8139 on e1000 machines or vice
versa just based on which ROM comes first... 

I suppose we could use a custom protocol to export a list of ID''s for a
ROM. I would suggest a header that goes before the ROM so as not to
interfere with the standards-conforming bits. We''d just have to
special-case ethernet ROM handling a bit more in hvmloader.

Ideally we want 1 ROM with support for both chipsets and therefore all
known variants of those chipsets. That would allow for HVM''s with card
of multiple types. But not figured out how to get gPXE to play like that
yet.
> -- Keir
Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/06/2010 13:01, "Gianni Tedesco (3P)"
<gianni.tedesco@citrix.com>
wrote:
> I suppose we could use a custom protocol to export a list of ID''s
for a
> ROM. I would suggest a header that goes before the ROM so as not to
> interfere with the standards-conforming bits. We''d just have to
> special-case ethernet ROM handling a bit more in hvmloader.
Especially if there is some scripted way we could scrape the IDs out of the
gpxe sources and into a customised header, this might be the best way to go.

I don''t know.. I suppose the alternative is to say that our gpxe build
only
supports our qemu build, adjust the advertised single PCI IDs to match up.
The only way we''d see other IDs is if someone passed through a real
device,
and in that case there''s no guarantee it''d be an e1000 or
rtl8139 anyway. In
which case they''d need to build their own gpxe image anyway.

So.... Perhaps this is all a big bunch of waste of time and we should just
go with your first patch after all and be done? :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/06/2010 13:01, "Gianni Tedesco (3P)"
<gianni.tedesco@citrix.com>
wrote:
> Ideally we want 1 ROM with support for both chipsets and therefore all
> known variants of those chipsets. That would allow for HVM''s with
card
> of multiple types. But not figured out how to get gPXE to play like that
> yet.
One issue here is that a ''mega ROM'' may not fit in the option
ROM space.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2010-06-29 at 13:22 +0100, Keir Fraser wrote:
> On 29/06/2010 13:01, "Gianni Tedesco (3P)"
<gianni.tedesco@citrix.com>
> wrote:
> 
> > I suppose we could use a custom protocol to export a list of
ID''s for a
> > ROM. I would suggest a header that goes before the ROM so as not to
> > interfere with the standards-conforming bits. We''d just have
to
> > special-case ethernet ROM handling a bit more in hvmloader.
> 
> Especially if there is some scripted way we could scrape the IDs out of the
> gpxe sources and into a customised header, this might be the best way to
go.
>
> I don''t know.. I suppose the alternative is to say that our gpxe
build only
> supports our qemu build, adjust the advertised single PCI IDs to match up.
> The only way we''d see other IDs is if someone passed through a
real device,
> and in that case there''s no guarantee it''d be an e1000 or
rtl8139 anyway. In
> which case they''d need to build their own gpxe image anyway.
True, but in fact, couldn''t the ROM just be pulled from the device in
that case?
> So.... Perhaps this is all a big bunch of waste of time and we should just
> go with your first patch after all and be done? :-)
> 
>  -- Keir
Heh, I''d say so, you could always just add a list of PCI-ID based ROM
target-names in to the etherboot Makefile... All it does is to bloat the
hvmloader image a bit.

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> The only way we''d see other IDs is if someone passed through a
real
device,
> and in that case there''s no guarantee it''d be an e1000 or
rtl8139
anyway. In
> which case they''d need to build their own gpxe image anyway.
> 
Wouldn''t PCI passthrough map through the option ROM on the PCI adapter
though, negating the need to use gPXE? I''m don''t think
I''ve met a
network adapter in quite a few years that didn''t have some form of PXE
support built in.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2010-06-29 at 13:24 +0100, Keir Fraser wrote:
> On 29/06/2010 13:01, "Gianni Tedesco (3P)"
<gianni.tedesco@citrix.com>
> wrote:
> 
> > Ideally we want 1 ROM with support for both chipsets and therefore all
> > known variants of those chipsets. That would allow for HVM''s
with card
> > of multiple types. But not figured out how to get gPXE to play like
that
> > yet.
> 
> One issue here is that a ''mega ROM'' may not fit in the
option ROM space.
True if it were really "mega" but if it were just the 2 drivers we
build
ROM''s for anyway it''s still in a similar ballpark. eg. 65KB
-> 89KB...
Anyway, probably better to avoid cluttering the space unnecessarily.

The only upside to this is to have that nice swish gPXE gui be able to
use all available cards, select which one to boot from etc...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/06/2010 13:30, "Gianni Tedesco (3P)"
<gianni.tedesco@citrix.com>
wrote:
>> So.... Perhaps this is all a big bunch of waste of time and we should
just
>> go with your first patch after all and be done? :-)
> 
> Heh, I''d say so, you could always just add a list of PCI-ID based
ROM
> target-names in to the etherboot Makefile... All it does is to bloat the
> hvmloader image a bit.
Yes indeed. I applied your original patch and I actually removed the default
eb-roms.h file so everyone will build their own GPXE ROM(s). It should be
easy for people who care to tweak the target list and it doesn''t much
matter
how bloated hvmloader gets, within reason. Now that you removed -Werror from
gpxe''s build flags, and I''ve forced ROMs to build serially, I
hope the gpxe
build system will be robust enough to build correctly on most people''s
systems.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/06/2010 13:33, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> Wouldn''t PCI passthrough map through the option ROM on the PCI
adapter
> though, negating the need to use gPXE? I''m don''t think
I''ve met a
> network adapter in quite a few years that didn''t have some form of
PXE
> support built in.
Agreed but for some reason when Intel implemented option ROM passthrough
(xen-unstable:18808) they restricted it to mass-storage and
serial-controller devices only (PCI classes 0x1 and 0xc). No idea why. :-)
It obviously shows noone (yet) has wanted to use a pass-through NIC option
ROM! Doubtless this will get picked up and fixed/altered at some point. At
the very least adding NICs to the PCI-class whitelist would seem pretty
harmless....

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel