Re: [virtio-dev] Memory sharing device

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Roman Kiryanov <rkir@google.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	virtio-dev@lists.oasis-open.org, Lingfeng Yang <lfy@google.com>
Subject: Re: [virtio-dev] Memory sharing device
Date: Tue, 12 Feb 2019 09:03:39 -0500	[thread overview]
Message-ID: <20190212090121-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190212144741.60083682.cohuck@redhat.com>

On Tue, Feb 12, 2019 at 02:47:41PM +0100, Cornelia Huck wrote:
> On Tue, 12 Feb 2019 11:25:47 +0000
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> 
> > * Roman Kiryanov (rkir@google.com) wrote:
> > > > > 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?  
> > > 
> > > We looked into UIO and it still requires some kernel driver to tell
> > > where the device is, it also has limitations on sharing a device
> > > between processes. The benefit of standardization could be in avoiding
> > > everybody writing their own UIO drivers for virtual devices.
> > > 
> > > Our emulator uses a battery, sound, accelerometer and more. We need to
> > > support all of this. I looked into the spec, "5 Device types", and
> > > seems "battery" is not there. We can invent our own drivers but we see
> > > having one flexible driver is a better idea.  
> > 
> > Can you group these devices together at all in their requirements?
> > For example, battery and accelerometers (to me) sound like low-bandwidth
> > 'sensors' with a set of key,value pairs that update occasionally
> > and a limited (no?) amount of control from the VM->host.
> > A 'virtio-values' device that carried a string list of keys that it
> > supported might make sense and be enough for at least two of your
> > device types.
> 
> Maybe not a 'virtio-values' device -- but a 'virtio-sensors' device
> looks focused enough without being too inflexible. It can easily
> advertise its type (battery, etc.) and therefore avoid the mismatch
> problem that a too loosely defined device would be susceptible to.

Isn't virtio-vsock/vhost-vsock a good fit for this kind of general
string passing? People seem to use it exactly for this.

> > > Yes, I realize that a guest could think it is using the same device as
> > > the host advertised (because strings matched) while it is not. We
> > > control both the host and the guest and we can live with this.
> 
> The problem is that this is not true for the general case if you have a
> standardized device type. It must be possible in theory to switch to an
> alternative implementation of the device or the driver, as long as they
> conform to the spec. I think a more concretely specified device type
> (like the suggested virtio-values or virtio-sensors) is needed for that.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

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