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

Eric Van Hensbergen
2007-05-11T22:21:44Z

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:
a) does it communicate with userspace, kernelspace, or both?
b) is it multi-channel? prioritized? interrupt driven or poll driven?
c) how big are the buffers? is it packetized?
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

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