virtio — archive

[Stefan Hajnoczi <stefanha@redhat.com>]

On Tue, Aug 06, 2013 at 08:55:27AM -0500, Anthony Liguori wrote: > Stefan Hajnoczi <stefanha@redhat.com> writes: > > > On Mon, Aug 05, 2013 at 12:22:06PM -0400, Sasha Levin wrote: > >> We seem to have a family of several devices that are rather simple on the virtio level. Some > >> identifying features include: > >> > >> * No real usage of the configuration space > >> * No device features > >> * No control vqs > >> * Usually one, but possibly 2 vqs used for straightforward message passing outside the virtio > >> scope. > >> > >> The use case is simple: use virtio as a simple transport for protocol specific messages, this > >> can pretty much go over any other transport exactly the same way. > >> > >> Would it make sense to move their actual definition out of the spec and just reserve device > >> IDs for them there? > > > > Why don't they use virtio-serial or the new vsock from the start? Both > > transports are built to support arbitrary protocols for tasks that don't > > need virtio device-level features. Seems like the right fit instead of > > reserving unique virtio device IDs. > > IMHO, anything that may be of interest across multiple guests and > multiple hypervisors should be considered for formal specification. > > I don't think the answer should be to tunnel everything through > virtio-serial or vsock. There's nothing wrong with simple virtio > devices. > > A reasonable analogy is the HID specification for USB. It supports a > very large number of often simple devices. It's pretty useful to have > standard drivers for such devices because then there is no need for > vendor specific drivers. If the devices are simple and don't re-invent virtio-serial or vsock, then I agree. But I actually misunderstood Sasha, I thought he was referring to new, custom devices rather than things like 9p or rng. Stefan