[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: A new direction for vmchannel?
From: |
Chris Wright |
Subject: |
[Qemu-devel] Re: A new direction for vmchannel? |
Date: |
Fri, 23 Jan 2009 09:12:51 -0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
* Anthony Liguori (address@hidden) 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
[Qemu-devel] Re: A new direction for vmchannel?, Daniel P. Berrange, 2009/01/24