Re: [RFC PATCH v3 2/3] VFIO driver for vGPU device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,

Alex
--
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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux