From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoJow-00028S-2x for qemu-devel@nongnu.org; Tue, 02 Aug 2011 14:36:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoJou-0007AI-UQ for qemu-devel@nongnu.org; Tue, 02 Aug 2011 14:36:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoJou-0007A8-LB for qemu-devel@nongnu.org; Tue, 02 Aug 2011 14:36:00 -0400 From: Alex Williamson Date: Tue, 02 Aug 2011 12:35:19 -0600 In-Reply-To: <1312308847.2653.467.camel@bling.home> References: <1311983933.8793.42.camel@pasglop> <1312050011.2265.185.camel@x201.home> <20110802082848.GD29719@yookeroo.fritz.box> <1312308847.2653.467.camel@bling.home> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1312310121.2653.470.camel@bling.home> Mime-Version: 1.0 Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: aafabbri , Alexey Kardashevskiy , kvm@vger.kernel.org, Paul Mackerras , qemu-devel , chrisw , iommu , "linux-pci@vger.kernel.org" , linuxppc-dev , benve@cisco.com On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote: > On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote: > > On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote: > > > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote: > > [snip] > > > On x86, the USB controllers don't typically live behind a PCIe-to-PCI > > > bridge, so don't suffer the source identifier problem, but they do often > > > share an interrupt. But even then, we can count on most modern devices > > > supporting PCI2.3, and thus the DisINTx feature, which allows us to > > > share interrupts. In any case, yes, it's more rare but we need to know > > > how to handle devices behind PCI bridges. However I disagree that we > > > need to assign all the devices behind such a bridge to the guest. > > > There's a difference between removing the device from the host and > > > exposing the device to the guest. > > > > I think you're arguing only over details of what words to use for > > what, rather than anything of substance here. The point is that an > > entire partitionable group must be assigned to "host" (in which case > > kernel drivers may bind to it) or to a particular guest partition (or > > at least to a single UID on the host). Which of the assigned devices > > the partition actually uses is another matter of course, as is at > > exactly which level they become "de-exposed" if you don't want to use > > all of then. > > Well first we need to define what a partitionable group is, whether it's > based on hardware requirements or user policy. And while I agree that > we need unique ownership of a partition, I disagree that qemu is > necessarily the owner of the entire partition vs individual devices. Sorry, I didn't intend to have such circular logic. "... I disagree that qemu is necessarily the owner of the entire partition vs granted access to devices within the partition". Thanks, Alex