WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Fix etherboot option ROM loading

To: "Gianni Tedesco (3P)" <gianni.tedesco@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Fix etherboot option ROM loading
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 29 Jun 2010 13:22:22 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 29 Jun 2010 05:23:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1277812883.5325.110.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsXgm2FSmmYu7XYS+mj1lFMq+zVCgAA0v0E
Thread-topic: [Xen-devel] [PATCH] Fix etherboot option ROM loading
User-agent: Microsoft-Entourage/12.24.0.100205
On 29/06/2010 13:01, "Gianni Tedesco (3P)" <gianni.tedesco@xxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel