From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQPye-0005us-03 for qemu-devel@nongnu.org; Fri, 23 Jan 2009 12:37:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQPyc-0005uO-CE for qemu-devel@nongnu.org; Fri, 23 Jan 2009 12:37:55 -0500 Received: from [199.232.76.173] (port=33522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQPyc-0005uH-8A for qemu-devel@nongnu.org; Fri, 23 Jan 2009 12:37:54 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:38361) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQPyb-00011V-R1 for qemu-devel@nongnu.org; Fri, 23 Jan 2009 12:37:54 -0500 Received: by qyk13 with SMTP id 13so7603562qyk.10 for ; Fri, 23 Jan 2009 09:37:49 -0800 (PST) Message-ID: <497A005E.8000701@codemonkey.ws> Date: Fri, 23 Jan 2009 11:37:34 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4979D80D.307@us.ibm.com> <20090123171251.GB3622@x200.localdomain> In-Reply-To: <20090123171251.GB3622@x200.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: 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: Chris Wright Cc: Eric Van Hensbergen , Anthony Liguori , kvm-devel , Gleb Natapov , Dor Laor , "qemu-devel@nongnu.org" , Avi Kivity Chris Wright wrote: > * 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? > Well, it doesn't exactly have to be vmchannel, but the desire is to have the management tools to be able to communicate directly with a kernel driver. We could certainly just use virtio and route it through QEMU to the management tool. It would be useful to just use vmchannel though. >> 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...)? > I think you end up having a lot of the same issues with respect to making it transparent to the guest. You could still do 9p over serial and still use a synthetic file system in the guest. In fact, this is a pretty reasonable thing to do for older kernel guests and even Windows. Regards, Anthony Liguori > thanks, > -chris > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >