Re: [virtio-dev] Memory sharing device

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Frank Yang <lfy@google.com>
Cc: Roman Kiryanov <rkir@google.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	virtio-dev@lists.oasis-open.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [virtio-dev] Memory sharing device
Date: Mon, 11 Feb 2019 11:57:50 -0500	[thread overview]
Message-ID: <20190211103652-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAEkmjvVzmfUmu3DDXSSPqTBqXNMyp65sy28xhSiigRGftGiyXw@mail.gmail.com>

On Mon, Feb 11, 2019 at 07:14:53AM -0800, Frank Yang wrote:
> 
> 
> 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.

As long standartization facilitates functionality, e.g.
if we can support moving between hypervisors, this seems
in-scope for virtio.

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

virtio gpu is part of the csprd01 draft.

> 
> 
>     --
>     MST
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org