Re: A new direction for vmchannel?

Chris Wright
2009-01-23T17:13:58Z

* Anthony Liguori (aliguori@us.ibm.com) wrote:
> The userspace configuration aspects of the current implementation of
> vmchannel are pretty annoying. Moreover, we would like to make use of
> something like vmchannel in a kernel driver and I fear that it's going
> to be difficult to do that.

What's the use for vmchannel from kernel driver?

> So here's an alternative proposal.
>
> Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs. This
> is all upstream. We backported the v9fs modules all the way back to
> 2.6.18. I have a 9p client and server library and patches available for
> QEMU. We were using this for a file system pass through but we could
> also use it as a synthetic file system in the guest (like sysfs).
>
> The guest would just have to mount a directory in a well known location,
> and then you could get vmchannel like semantics by just opening a file
> read/write. Better yet though would be if we actually exposed vmchannel
> as 9p so that management applications could implement sysfs-like
> hierarchies.
>
> I think there could be a great deal of utility in something like. For
> portability to Windows (if an app cared), it would have to access the
> mount point through a library of some sort. We would need a Windows
> virtio-9p driver that exposed the 9p session down to userspace. We
> could then use our 9p client library in the portability library for
> Windows.
>
> Virtually all of the code is available for this today, the kernel bits
> are already upstream, there's a reasonable story for Windows, and
> there's very little that the guest can do to get in the way of things.
>
> The only thing that could potentially be an issue is SELinux. I assume
> you'd have to do an SELinux policy for the guest application anyway
> though so it shouldn't be a problem.
>
> Thoughts?

Heh, works for me ;-) Last time I suggested an fs it got shot down due to
the burden it puts on the guest implementation (notably windows and
other guests and ease of adding a new fs implementation).

Doesn't directly solve addressing (IOW, easy to do with hierarchical
namespace, but if vmchannel ever talks guest-to-guest...). Clearly not
a huge issue.

Should handle the reliable messaging bit (one big push for using tcp),
and has advantage of being a structured protocol.

Has the similar ABI issue that we see in Linux with sysfs, namely it's
easy to screw up...but that is manageable.

BTW, what ever happened to just using a serial device (granted needs
some protocol layered on top...)?

thanks,
-chris