From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neo Jia Subject: Re: [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu Date: Fri, 13 May 2016 00:38:05 -0700 Message-ID: <20160513073805.GB5749@nvidia.com> References: <5731933B.90508@intel.com> <20160510160257.GA4125@nvidia.com> <5732F823.3090409@intel.com> <20160511160628.690876f9@t450s.home> <20160512194924.GA24334@nvidia.com> <57356F64.1010406@intel.com> <20160513064153.GA30970@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Ruan, Shuai" , "Song, Jike" , "kvm@vger.kernel.org" , Jike Song , Kirti Wankhede , "qemu-devel@nongnu.org" , Alex Williamson , "kraxel@redhat.com" , "pbonzini@redhat.com" , "Lv, Zhiyuan" To: "Tian, Kevin" Return-path: Content-Disposition: inline In-Reply-To: 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" List-Id: kvm.vger.kernel.org On Fri, May 13, 2016 at 07:13:44AM +0000, Tian, Kevin wrote: > > From: Neo Jia [mailto:cjia@nvidia.com] > > Sent: Friday, May 13, 2016 2:42 PM > > > > > > > > > > We possibly have the same requirement from the mediate driver backend: > > > > > > a) get a GFN, when guest try to tell hardware; > > > b) consult the vfio iommu with that GFN[1]: will you find me a proper dma_addr? > > > > We will provide you the pfn via vfio_pin_pages, so you can map it for dma > > purpose in your i915 driver, which is what we are doing today. > > > > Can such 'map' operation be consolidated in vGPU core driver? I don't think > Intel vGPU driver has any feature proactively relying on iommu. The reason > why we keep talking iommu is just because the kernel may enable iommu > for physical GPU so we need make sure our device model can work in such > configuration. And this requirement should apply to all vendors, not Intel > specific (like you said you are doing it already today). Hi Kevin, Actually, such requirement is already satisfied today as all vendor drivers should transparently work with and without system iommu on bare-metal, right? So I don't see any new requirement here, also such consolidation doesn't help any but adding complexity to the system as vendor driver will not remove their own dma_map_xxx functions as they are still required to support non-mediated cases. Thanks, Neo > > Thanks > Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b17fp-0001RY-HS for qemu-devel@nongnu.org; Fri, 13 May 2016 03:38:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b17fk-00025H-Vn for qemu-devel@nongnu.org; Fri, 13 May 2016 03:38:12 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:11839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b17fk-00025D-Mk for qemu-devel@nongnu.org; Fri, 13 May 2016 03:38:08 -0400 Date: Fri, 13 May 2016 00:38:05 -0700 From: Neo Jia Message-ID: <20160513073805.GB5749@nvidia.com> References: <5731933B.90508@intel.com> <20160510160257.GA4125@nvidia.com> <5732F823.3090409@intel.com> <20160511160628.690876f9@t450s.home> <20160512194924.GA24334@nvidia.com> <57356F64.1010406@intel.com> <20160513064153.GA30970@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" Cc: "Song, Jike" , Jike Song , Alex Williamson , Kirti Wankhede , "pbonzini@redhat.com" , "kraxel@redhat.com" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Ruan, Shuai" , "Lv, Zhiyuan" On Fri, May 13, 2016 at 07:13:44AM +0000, Tian, Kevin wrote: > > From: Neo Jia [mailto:cjia@nvidia.com] > > Sent: Friday, May 13, 2016 2:42 PM > > > > > > > > > > We possibly have the same requirement from the mediate driver backend: > > > > > > a) get a GFN, when guest try to tell hardware; > > > b) consult the vfio iommu with that GFN[1]: will you find me a proper dma_addr? > > > > We will provide you the pfn via vfio_pin_pages, so you can map it for dma > > purpose in your i915 driver, which is what we are doing today. > > > > Can such 'map' operation be consolidated in vGPU core driver? I don't think > Intel vGPU driver has any feature proactively relying on iommu. The reason > why we keep talking iommu is just because the kernel may enable iommu > for physical GPU so we need make sure our device model can work in such > configuration. And this requirement should apply to all vendors, not Intel > specific (like you said you are doing it already today). Hi Kevin, Actually, such requirement is already satisfied today as all vendor drivers should transparently work with and without system iommu on bare-metal, right? So I don't see any new requirement here, also such consolidation doesn't help any but adding complexity to the system as vendor driver will not remove their own dma_map_xxx functions as they are still required to support non-mediated cases. Thanks, Neo > > Thanks > Kevin