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

[Gerd Hoffmann]

  Hi,

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

Yes, using a PCI bar to reserve some address space would be a safe way
to handle this.

I still think we should try to do it the other way around:  Not map the
host ressources into the guest, but make the guest resources usable by
the host.  Have a little helper driver which can turn the virtio-gpu
ressource iov into a dmabuf (standalone or pimped up vgem), then run
with that, to avoid the memcpy.  Possibly the gpu driver still has to
copy stuff then, or the gpu copy itself via dma, but the gpu driver
should be able to do whatever is best for the given host hardware ...

First attempt on a standalone driver:
	git://git.kraxel.org/linux udmabuf-gup-broken

Uses get-user-pages, not going to work reliable with fork(2) (due to cow
being fundamentally incompatible with dma-bufs).

Second attempt (wip still, due to being busy with other stuff atm,
doesn't even compile ...), supporting only memfd/shmem as backing
storage for dmabufs:
	git://git.kraxel.org/linux udmabuf

> This is a bit of a stickler for me, I'm not sure the qemu folks would want to
> pull a rust build dependency into the tree,

As I've understand things this was ment as alternative implementation,
so rust would be an optional dependency.  But of course it implies we
will have to maintain both rust and C version of the code ...

cheers,
  Gerd