OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] Re: [virtio] Re: [virtio-comment] *-over-virtio

On 08/07/2013 02:11 AM, Rusty Russell wrote:
Sasha Levin <sasha.levin@oracle.com> writes:
On 08/05/2013 11:48 PM, Rusty Russell wrote:
Sasha Levin <sasha.levin@oracle.com> writes:
Hi all,

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

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?

Do we have any in the current spec?  It's certainly easy to reserve IDs
for things which aren't in the spec.

virtio-rng and virtio-9p are good examples of that. Maybe virtio-rpmsg too, depends on how
you stretch that description above.

Well, virtio-9p has a feature, and it uses the configuration space.

Is it really useful to draw out these as a separate class?  Seems like
it's more a spectrum than a clear line.

The single feature it has *must* always be set, and the config space is the thing specified by
the feature, which is a single string that can never be changed in the lifetime of the device.

So while virtio-9p does have those two defined in the spec it's not really making any special
use of them like the rest of the devices do.

I just suspect that this class of devices will start being popular since virtio works extremely well
just as a very basic host-guest transport, without really needing any of it's other features, so
some way to have a common "base" devices that can be used for those types of devices, in addition to
be able to use "user defined" devices may keep it simple for those types of devices in the future.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]