From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0aT5-0005fv-2O for qemu-devel@nongnu.org; Wed, 11 May 2016 16:10:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0aSz-0004k8-Fl for qemu-devel@nongnu.org; Wed, 11 May 2016 16:10:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0aSz-0004jo-5G for qemu-devel@nongnu.org; Wed, 11 May 2016 16:10:45 -0400 Date: Wed, 11 May 2016 14:10:43 -0600 From: Alex Williamson Message-ID: <20160511141043.2898ef42@t450s.home> In-Reply-To: References: <1462214441-3732-1-git-send-email-kwankhede@nvidia.com> <1462214441-3732-3-git-send-email-kwankhede@nvidia.com> <20160503164326.14dafcf5@t450s.home> <20160504110619.1c75cb69@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" Cc: Kirti Wankhede , "pbonzini@redhat.com" , "kraxel@redhat.com" , "cjia@nvidia.com" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Ruan, Shuai" , "Song, Jike" , "Lv, Zhiyuan" On Wed, 11 May 2016 06:45:41 +0000 "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Thursday, May 05, 2016 1:06 AM > > > > > + > > > > > + ret = remap_pfn_range(vma, virtaddr, pgoff, req_size, pg_prot); > > > > > > > > So not supporting validate_map_request() means that the user can > > > > directly mmap BARs of the host GPU and as shown below, we assume a 1:1 > > > > mapping of vGPU BAR to host GPU BAR. Is that ever valid in a vGPU > > > > scenario or should this callback be required? It's not clear to me how > > > > the vendor driver determines what this maps to, do they compare it to > > > > the physical device's own BAR addresses? > > > > > > I didn't quite understand too. Based on earlier discussion, do we need > > > something like this, or could achieve the purpose just by leveraging > > > recent sparse mmap support? > > > > The reason for faulting in the mmio space, if I recall correctly, is to > > enable an ordering where the user driver (QEMU) can mmap regions of the > > device prior to resources being allocated on the host GPU to handle > > them. Sparse mmap only partially handles that, it's not dynamic. With > > this faulting mechanism, the host GPU doesn't need to commit resources > > until the mmap is actually accessed. Thanks, > > > > Alex > > Just double confirm. I assume this faulting mechanism can work with > sparse mmap, right? Regardless of whether it's a full or partial region, > this faulting mechanism would commit resource only when accessed > page has MMAP flag set... Yes, the vfio sparse mmap just solves the problem that a vfio region maps to an entire device resource, for example in the case of vfio-pci, a PCI BAR. It turns out that specifying mmap on a whole region doesn't give us the granularity we need. Sparse mmap gives us a generic way to tell userspace which areas within a region support mmap and which should use read/write access through the vfio device file descriptor. The latter allows us to protect specific regions or provide further emulation/virtualization for that sub-area. How the mmap vma is populated for the portions that do support mmap is an orthogonal issue. Thanks, Alex