On Tue, Feb 12, 2019 at 12:27:54AM -0800, Roman Kiryanov 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.
So it sounds like you should use virtio-vsock or a serial device
for most of your needs. For gpu, I'd use virtio-gpu probably improving
it as IIUC you have concerns about resource management.
> 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.
>
> Regards,
> Roman.
I suggest you layer on top of some other existing device then.
Most people don't build their own transport layer on a whim
just because they control both communicating sides.
There should be more of a reason for this.
--
MST
