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/
Home Products Support Community News


Re: [Xen-devel] [PATCH 4 of 5] libxl: Add support for passing in the mac

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...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>