From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roedel, Joerg" Subject: Re: kvm PCI assignment & VFIO ramblings Date: Thu, 25 Aug 2011 18:46:01 +0200 Message-ID: <20110825164601.GK1923@amd.com> References: <1314118861.2859.51.camel@bling.home> <20110824091035.GD2079@amd.com> <1314220434.2859.203.camel@bling.home> <20110825105402.GB1923@amd.com> <4E566C61.9060105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , qemu-devel , iommu , chrisw , Alex Williamson , Avi Kivity , "linux-pci@vger.kernel.org" , linuxppc-dev , "benve@cisco.com" To: Don Dutile Return-path: Content-Disposition: inline In-Reply-To: <4E566C61.9060105@redhat.com> 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 Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote: > On 08/25/2011 06:54 AM, 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. > > > When you think of a system where there isn't just one bus-type > with iommu support, it makes more sense. > Additionally, it also allows the long-term architecture to use different types > of IOMMUs on each bus segment -- think per-PCIe-switch/bridge IOMMUs -- > esp. 'tuned' IOMMUs -- ones better geared for networks, ones better geared > for direct-attach disk hba's. Not sure how likely it is to have different types of IOMMUs within a given bus-type. But if they become reality we can multiplex in the iommu-api without much hassle :) For now, something like bus_set_iommu() or bus_register_iommu() would provide a nice way to do bus-specific setups for a given iommu implementation. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 5B0F0B6F8F for ; Fri, 26 Aug 2011 02:48:34 +1000 (EST) Date: Thu, 25 Aug 2011 18:46:01 +0200 From: "Roedel, Joerg" To: Don Dutile Subject: Re: kvm PCI assignment & VFIO ramblings Message-ID: <20110825164601.GK1923@amd.com> References: <1314118861.2859.51.camel@bling.home> <20110824091035.GD2079@amd.com> <1314220434.2859.203.camel@bling.home> <20110825105402.GB1923@amd.com> <4E566C61.9060105@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4E566C61.9060105@redhat.com> Cc: Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , qemu-devel , iommu , chrisw , Alex Williamson , Avi Kivity , Anthony Liguori , "linux-pci@vger.kernel.org" , linuxppc-dev , "benve@cisco.com" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote: > On 08/25/2011 06:54 AM, 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. > > > When you think of a system where there isn't just one bus-type > with iommu support, it makes more sense. > Additionally, it also allows the long-term architecture to use different types > of IOMMUs on each bus segment -- think per-PCIe-switch/bridge IOMMUs -- > esp. 'tuned' IOMMUs -- ones better geared for networks, ones better geared > for direct-attach disk hba's. Not sure how likely it is to have different types of IOMMUs within a given bus-type. But if they become reality we can multiplex in the iommu-api without much hassle :) For now, something like bus_set_iommu() or bus_register_iommu() would provide a nice way to do bus-specific setups for a given iommu implementation. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwd6Y-0007O0-7a for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:48:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qwd6X-0006ED-90 for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:48:34 -0400 Received: from tx2ehsobe002.messaging.microsoft.com ([65.55.88.12]:19729 helo=TX2EHSOBE004.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwd6X-0006Dx-3w for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:48:33 -0400 Date: Thu, 25 Aug 2011 18:46:01 +0200 From: "Roedel, Joerg" Message-ID: <20110825164601.GK1923@amd.com> References: <1314118861.2859.51.camel@bling.home> <20110824091035.GD2079@amd.com> <1314220434.2859.203.camel@bling.home> <20110825105402.GB1923@amd.com> <4E566C61.9060105@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4E566C61.9060105@redhat.com> Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Don Dutile Cc: Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , qemu-devel , iommu , chrisw , Alex Williamson , Avi Kivity , "linux-pci@vger.kernel.org" , linuxppc-dev , "benve@cisco.com" On Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote: > On 08/25/2011 06:54 AM, 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. > > > When you think of a system where there isn't just one bus-type > with iommu support, it makes more sense. > Additionally, it also allows the long-term architecture to use different types > of IOMMUs on each bus segment -- think per-PCIe-switch/bridge IOMMUs -- > esp. 'tuned' IOMMUs -- ones better geared for networks, ones better geared > for direct-attach disk hba's. Not sure how likely it is to have different types of IOMMUs within a given bus-type. But if they become reality we can multiplex in the iommu-api without much hassle :) For now, something like bus_set_iommu() or bus_register_iommu() would provide a nice way to do bus-specific setups for a given iommu implementation. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632