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

[Tian, Kevin]

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

Thanks
Kevin