From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 0 of 5] Patches for PCI passthrough with modified E820. Date: Fri, 8 Apr 2011 09:24:51 -0400 Message-ID: <20110408132451.GD6189@dumpdata.com> References: <1302252124.27835.66.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1302252124.27835.66.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org 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.