Re: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

[Alex Williamson <alex.williamson@redhat.com>]

On Mon, 2016-02-01 at 14:10 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Unfortunately it's not the only one. Another example is, device-model
> > > may want to write-protect a gfn (RAM). In case that this request goes
> > > to VFIO .. how it is supposed to reach KVM MMU?
> > 
> > Well, let's work through the problem.  How is the GFN related to the
> > device?  Is this some sort of page table for device mappings with a base
> > register in the vgpu hardware?
> 
> IIRC this is needed to make sure the guest can't bypass execbuffer
> verification and works like this:
> 
>   (1) guest submits execbuffer.
>   (2) host makes execbuffer readonly for the guest
>   (3) verify the buffer (make sure it only accesses resources owned by
>       the vm).
>   (4) pass on execbuffer to the hardware.
>   (5) when the gpu is done with it make the execbuffer writable again.

Ok, so are there opportunities to do those page protections outside of
KVM?  We should be able to get the vma for the buffer, can we do
something with that to make it read-only.  Alternatively can the vgpu
driver copy it to a private buffer and hardware can execute from that?
I'm not a virtual memory expert, but it doesn't seem like an
insurmountable problem.  Thanks,

Alex