[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4 of 5] libxl: Add support for passing in the machine's E820 for PCI passthrough



On Fri, 2011-04-08 at 14:35 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 08, 2011 at 11:56:52AM +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 4 of 5] libxl: Add support for 
> > passing in the machine's E820 for PCI passthrough"):
> > > Are we expecting that libxl users might want to modify the e820? If not
> > > then why expose libxl_e820_alloc and libxl_e820_sanitize at all, just
> > > add a flag to the libxl interface which says whether or not to provide a
> > > host-derived e820.
> > 
> > Well, also, why do we need that flag at all ?  Are we trying to do
> > something different with domains which might get pci passthrough ?  If
> 
> Yes. Well, it does work OK even if you are _not_ doing PCI passthrough.
> But the main users for this are the ones doing PCI passthrough.
> 
> > so then that's what should be specified at the libxl api, surely,
> > rather than some opaque "write this rune to make it work" option.
> 
> OK. If I am understanding you guys right, you are saying, latch
> it of the 'pci' option instead of this 'pci_hole' option.

ACK. For the pure-hotplug case an empty pci=[] ought to suffice to
trigger this functionality.

> And do not expose thse libxl_e820_* functions, but keep them
> internal to the libxl code.

Yes, assuming we aren't expecting anyone to modify the table between
getting it from libxl and handing it back to libxl we should simply not
expose it. We can always expose it later if need be...

Ian.




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.