From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx0lj-0000GL-UQ for qemu-devel@nongnu.org; Fri, 26 Aug 2011 14:04:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qx0li-0000Cr-UV for qemu-devel@nongnu.org; Fri, 26 Aug 2011 14:04:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx0li-0000Cn-Hj for qemu-devel@nongnu.org; Fri, 26 Aug 2011 14:04:38 -0400 From: Alex Williamson Date: Fri, 26 Aug 2011 12:04:22 -0600 In-Reply-To: <20110825180557.GD8978@8bytes.org> References: <1314118861.2859.51.camel@bling.home> <20110824091035.GD2079@amd.com> <1314220434.2859.203.camel@bling.home> <20110825105402.GB1923@amd.com> <1314292832.2492.31.camel@x201.home> <20110825180557.GD8978@8bytes.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1314381863.2859.312.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: Joerg Roedel Cc: chrisw , Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , "Roedel, Joerg" , "linux-pci@vger.kernel.org" , qemu-devel , Aaron Fabbri , iommu , Avi Kivity , linuxppc-dev , "benve@cisco.com" On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote: > On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote: > > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote: > > > > We need to solve this differently. ARM is starting to use the iommu-api > > > too and this definitly does not work there. One possible solution might > > > be to make the iommu-ops per-bus. > > > > That sounds good. Is anyone working on it? It seems like it doesn't > > hurt to use this in the interim, we may just be watching the wrong bus > > and never add any sysfs group info. > > I'll cook something up for RFC over the weekend. > > > > Also the return type should not be long but something that fits into > > > 32bit on all platforms. Since you use -ENODEV, probably s32 is a good > > > choice. > > > > The convenience of using seg|bus|dev|fn was too much to resist, too bad > > it requires a full 32bits. Maybe I'll change it to: > > int iommu_device_group(struct device *dev, unsigned int *group) > > If we really expect segment numbers that need the full 16 bit then this > would be the way to go. Otherwise I would prefer returning the group-id > directly and partition the group-id space for the error values (s32 with > negative numbers being errors). It's unlikely to have segments using the top bit, but it would be broken for an iommu driver to define it's group numbers using pci s:b:d.f if we don't have that bit available. Ben/David, do PEs have an identifier of a convenient size? I'd guess any hardware based identifier is going to use a full unsigned bit width. Thanks, Alex