* Anthony Liguori (aliguori@xxxxxxxxxx) 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
