> From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Thursday, May 12, 2016 4:11 AM > On Wed, 11 May 2016 06:45:41 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> 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, > Exactly! Thanks for confirmation. Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
