[virglrenderer-devel] Proposals for virtio-gpu and virglrenderer

[Zach Reizner]

On Fri, Apr 27, 2018 at 6:01 AM Tomeu Vizoso <tomeu.vizoso at collabora.com>
wrote:

> On 04/27/2018 03:05 AM, Dave Airlie wrote:
> >> I've been working on adding accelerated virtio-gpu support to crosvm as
> >> well as adding support for sending dmabufs across virtio-wayland for
> >> improved host-side compositor performance. Along the way, I've
encountered
> >> a few features that I would like to discuss to make things work better
for
> >> crosvm, and, I believe, other users of virtio-gpu/virglrenderer.
> >
> > Hey,
> >
> > I'm just back from a few weeks off so I might need help on these as I'm
> > not fully back up to speed.
> >>
> >> 1) Add mmap support to virtio-gpu
> >> 2) Add API to import buffers to virglrenderer
> >> 3) Harden virglrenderer using memory safe language
> >>
> >> Elaboration for each feature below:
> >>
> >> 1) Currently, the only way to fill a resource in virtio-gpu is either
via a
> >> transfer from the backing memory to the resource, or to submit commands
> >> that render to the resource. This is not optimal for software
rendering or
> >> texture upload situations because of the additional copy this transfer
> >> necessitates. I propose that an additional virtio-gpu command, perhaps
> >> gated by a virtio feature bit, be made that allows the guest to request
> >> mapping of a resource directly into guest physical address space. With
this
> >> virtio command, requests to mmap a virgio-gpu resource by the guest's
user
> >> space applications, perhaps through a DRM ioctl on the buffer object
handle
> >> or an mmap on the dmabuf/prime FD, could be fulfilled without
additional
> >> copy operations to flush data that was written.
> >
> > How does this deal with tiling/unmappable resources? Most of the
resources
> > we allocate end up in tile VRAM hopefully, this may not even be
mappable.
> > When you use the GL APIs to map it we end up getting a transfer not a
direct
> > map so you get a copy there. If we bypass GL and go straight to
exporting
> > the buffer, we just get a tiled buffer which isn't that useful.
> >
> > Lets then assume you only want to map linear strided resources, you
envisage
> > exporting a precreated resource to a dma-buf, and somehow mmaping
> > the pages behind that resource into the guest memory space.
> >
> > Now the rules for what you can map where in guest VM are a bit hazy for
me,
> > maybe someone can expend more on how we can do this, do we need a PCI
> > BAR to have these things appear in or can they end up in random guest
pages?
> > Gerd?

> Gerd will be able to give you a more authoritative answer, but last time
> we talked about it the only safe way of doing it is with PCI BARs.

> KVM_SET_USER_MEMORY_REGION is what crosvm uses atm, but Gerd warned that
> the guest kernel has no knowledge of the mapping, as it's not involved
> during the process.
One idea I was thinking about that would not invoke
KVM_SET_USER_MEMORY_REGION would be to have the guest allocate some pages
out of it's existing ordinary guest memory, pass that to the hypervisor
which would then mmap a given resource on top of the existing guest memory
mappings. Assuming KVM_CAP_SYNC_MMU, this change in mapping would
immediately be reflected in the guest.

> Regards,

> Tomeu