From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: kvm PCI assignment & VFIO ramblings Date: Tue, 30 Aug 2011 18:13:43 +0200 Message-ID: <20110830161343.GB5203@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> <1314381863.2859.312.camel@bling.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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" To: Alex Williamson Return-path: Content-Disposition: inline In-Reply-To: <1314381863.2859.312.camel@bling.home> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote: > On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote: > > 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. Okay, if we want to go the secure way I am fine with the "int *group" parameter. Another option is to just return u64 and use the extended number space for errors. But that is even worse as an interface, I think. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 8bytes.org (8bytes.org [88.198.83.132]) by ozlabs.org (Postfix) with ESMTP id 725BDB6F86 for ; Wed, 31 Aug 2011 02:13:46 +1000 (EST) Date: Tue, 30 Aug 2011 18:13:43 +0200 From: Joerg Roedel To: Alex Williamson Subject: Re: kvm PCI assignment & VFIO ramblings Message-ID: <20110830161343.GB5203@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> <1314381863.2859.312.camel@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1314381863.2859.312.camel@bling.home> Cc: chrisw , Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , "Roedel, Joerg" , "linux-pci@vger.kernel.org" , qemu-devel , Aaron Fabbri , iommu , Avi Kivity , Anthony Liguori , linuxppc-dev , "benve@cisco.com" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote: > On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote: > > 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. Okay, if we want to go the secure way I am fine with the "int *group" parameter. Another option is to just return u64 and use the extended number space for errors. But that is even worse as an interface, I think. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyQwf-0001bn-FO for qemu-devel@nongnu.org; Tue, 30 Aug 2011 12:13:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyQwe-0007xD-GQ for qemu-devel@nongnu.org; Tue, 30 Aug 2011 12:13:49 -0400 Received: from 8bytes.org ([88.198.83.132]:57259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyQwe-0007vS-BP for qemu-devel@nongnu.org; Tue, 30 Aug 2011 12:13:48 -0400 Date: Tue, 30 Aug 2011 18:13:43 +0200 From: Joerg Roedel Message-ID: <20110830161343.GB5203@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> <1314381863.2859.312.camel@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314381863.2859.312.camel@bling.home> Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson 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 Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote: > On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote: > > 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. Okay, if we want to go the secure way I am fine with the "int *group" parameter. Another option is to just return u64 and use the extended number space for errors. But that is even worse as an interface, I think. Joerg