Re: [virtio-dev] Memory sharing device

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Feb 04, 2019 at 11:42:25PM -0800, Roman Kiryanov wrote:
> Hi Gerd,
> 
> > virtio-gpu specifically needs that to support vulkan and opengl
> > extensions for coherent buffers, which must be allocated by the host gpu
> > driver.  It's WIP still.
> 
> the proposed spec says:
> 
> +Shared memory regions MUST NOT be used to control the operation
> +of the device, nor to stream data; those should still be performed
> +using virtqueues.
> 
> Is there a strong reason to prohibit using memory regions for control purposes?

That's in order to make virtio have portability implications, such that if
people see a virtio device in lspci they know there's
no lock-in, their guest can be moved between hypervisors
and will still work.

> Our long term goal is to have as few kernel drivers as possible and to move
> "drivers" into userspace. If we go with the virtqueues, is there
> general a purpose
> device/driver to talk between our host and guest to support custom hardware
> (with own blobs)?

The challenge is to answer the following question:
how to do this without losing the benefits of standartization?

> Could you please advise if we can use something else to
> achieve this goal?

I am not sure what the goal is though. Blobs is a means I guess
or it should be :) E.g. is it about being able to iterate quickly?

Maybe you should look at vhost-user-gpu patches on qemu?
Would this address your need?
Acks for these patches would be a good thing.


-- 
MST