From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQNI6-0000GL-MC for qemu-devel@nongnu.org; Fri, 23 Jan 2009 09:45:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQNI4-0000CR-Sl for qemu-devel@nongnu.org; Fri, 23 Jan 2009 09:45:50 -0500 Received: from [199.232.76.173] (port=50464 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQNI4-0000By-99 for qemu-devel@nongnu.org; Fri, 23 Jan 2009 09:45:48 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:38646) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LQNI3-0004lu-S1 for qemu-devel@nongnu.org; Fri, 23 Jan 2009 09:45:47 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0NEhqsK003659 for ; Fri, 23 Jan 2009 09:43:52 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0NEjkoV175354 for ; Fri, 23 Jan 2009 09:45:46 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0NEjkcI010702 for ; Fri, 23 Jan 2009 09:45:46 -0500 Message-ID: <4979D80D.307@us.ibm.com> Date: Fri, 23 Jan 2009 08:45:33 -0600 From: Anthony Liguori MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] A new direction for vmchannel? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Eric Van Hensbergen , Chris Wright , kvm-devel , Dor Laor , "qemu-devel@nongnu.org" , Avi Kivity 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. 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? Regards, Anthony Liguori