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 0 of 5] Patches for PCI passthrough with modified

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] Patches for PCI passthrough with modified E820.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Fri, 8 Apr 2011 09:24:51 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 08 Apr 2011 06:25:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1302252124.27835.66.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>
References: <patchbomb.1302207921@xxxxxxxxxxxxxxxxxxxxxxx> <1302252124.27835.66.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
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