Re: [PATCH/RFC 7/9] Virtual network guest device driver

Anthony Liguori
2007-05-16T17:28:00Z

Eric Van Hensbergen wrote:
> On 5/11/07, Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> There's definitely a conversation to have here. There are going to be a
>> lot of small devices that would benefit from a common transport
>> mechanism. Someone mentioned a PV entropy device on LKML. A
>> host=>guest filesystem is another consumer of such an interface.
>>
>> I'm inclined to think though that the abstraction point should be the
>> transport and not the actual protocol. My concern with standardizing on
>> a protocol like 9p would be that one would lose some potential
>> optimizations (like passing PFN's directly between guest and host).
>>
>
> I think that there are two layers - having a standard, well defined,
> simple shared memory transport between partitions (or between
> emulators and the host system) is certainly a prerequisite. There are
> lots of different decisions to made here:

What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.

> a) does it communicate with userspace, kernelspace, or both?

sockets are usable for both userspace/kernespace.

> b) is it multi-channel? prioritized? interrupt driven or poll driven?

Of course, arguments can be made for any of these depending on the
circumstance. I think you'd have to start with something simple that
would cover the most number of users (non-multiplexed, interrupt driven).

> c) how big are the buffers? is it packetized?

This could probably be tweaked with sockopts. I suspect you would have
an implementation for Xen, KVM, etc. and support a common set of options
(and possible some per-VM type of options).

> d) can all of these parameters be something controllable from userspace?
> e) I'm sure there are many others that I can't be bothered to think
> of on a Friday

The biggest point of contention would probably be what goes in the
sockaddr structure.

Thoughts?

Regards,

Anthony Liguori

> Regardless of the details, I think we can definitely come together on
> a common mechanism here and avoid lots of duplication in the drivers
> are already there and which will follow. My personal preference is to
> keep things as simple and flat as possible. No XML, no multiple
> stacks and daemons to contend with.
>
> What runs on top of the transport is no doubt going to be a touchy
> subject for some time to come. Many of Ron's arguments for 9p mostly
> apply to this upper level. I/we will be pursuing this as a unified PV
> resource sharing mechanism over the next few months in combination
> with reorganization and optimization of the Linux 9p code. LANL has
> also been making progress in this same direction. I'd have gotten
> started sooner, but I was waiting for my new Thinkpad so that I can
> actually run KVM ;)
>
>>
>> So is there any reason to even tie 9p to KVM? Why not just have a
>> common PV transport that 9p can use. For certain things, it may make
>> sense (like v9fs).
>>
>
> Well, I think we were discussing tying KVM to 9p, not vice-versa.
>
> My personal view is that developing a generalized solution for
> resource sharing of all manner of devices and services across
> virtualization, emulation, and network boundaries is a better way to
> spend our time than writing a bunch of specific
> drivers/protocols/interfaces for each type of device and each type of
> interconnect.
>
> -eric