[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Memory sharing device
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]