[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device |
Date: |
Thu, 12 May 2016 00:59:59 +0000 |
> From: Alex Williamson [mailto:address@hidden
> Sent: Thursday, May 12, 2016 4:11 AM
> On Wed, 11 May 2016 06:45:41 +0000
> "Tian, Kevin" <address@hidden> 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
[Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver, Kirti Wankhede, 2016/05/02
Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver, Tian, Kevin, 2016/05/03
Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver, Tian, Kevin, 2016/05/12
Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver, Kirti Wankhede, 2016/05/04
Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver, Tian, Kevin, 2016/05/05