Re: [Xen-devel] [PATCH 0 of 5] Patches for PCI passthrough with modified E820.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Apr 08, 2011 at 09:42:04AM +0100, Ian Campbell wrote:
> On Thu, 2011-04-07 at 21:25 +0100, Konrad Rzeszutek Wilk wrote:
> 
> > This set of RFC patches allows a PV domain to see the machine's
> > E820 and figure out where the "PCI I/O" gap is and match it with the
> > reality.
> 
> Does the domain builder obey this memory map at all or is it a PV guests
> responsibility to take the linear p2m allocation it starts with a move
> stuff around to fit the map?

The PV guest is responsible.
> 
> > To use this patchset, the guest config file has to have the parameter
> > 'pci_hole=1' enabled (hmm, any ideas for a better name?) 
> 
> Is there any harm in just doing this for any guest configuration which
> has a "pci" option specified? (including the empty list "pci=[]" to
> handle guests which only want hotplug capabilities not an initial set of
> devices).

Good idea. Will key of from both of them (since you can do hotplug PCI
without having the 'pci' option present).
> 
> Or could we even go so far as to consider always doing this
> unconditionally?

Tempting. I would need to test the other older kernels to make sure I am
not breaking anything.
> 
> Will older pvops and/or classic-Xen kernels or other PV OSes misbehave

Older pvops work. Will test the 2.6.32, as the earliest one I tested
was the 2.6.36 and that worked quite well.

> if we do either of these? is having a default-on option which these
> users need to force off better or worse than a default-off option which
> the opposite set of people need to enable?

No idea. I just don't want to cause regressions so choose the
more conservative path... but that has the pitfalls of bit-rotting.

Let me do some more testing and see what happens.
> 
> Ian.

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