On Mon, Feb 11, 2019 at 6:49 AM Michael S. Tsirkin <mst@redhat.com> wrote:

> 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?
>
> Draft spec is incoming, but the basic idea is to standardize how to
enumerate, discover, and operate (with high performance) such userspace
drivers/devices; the basic operations would be standardized, and userspace
drivers would be constructed out of the resulting primitives.

> 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.
>
>
Is this it:

https://patchwork.kernel.org/patch/10444089/ ?

I'll check it out and try to discuss. Is there a draft spec for it as well?


>
> --
> MST
>