[Qemu-devel] Re: A new direction for vmchannel?

[Chris Wright <chrisw@redhat.com>]

* 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