From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45229 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwkWb-0007cP-Fw for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:11:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwkWZ-0005eT-Rh for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:11:41 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:54231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwkWZ-0005eF-Mq for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:11:39 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p27JqS3C027344 for ; Mon, 7 Mar 2011 14:52:28 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 7246F6E803C for ; Mon, 7 Mar 2011 19:11:25 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p280BP6x367596 for ; Mon, 7 Mar 2011 19:11:25 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p280BOKV016255 for ; Mon, 7 Mar 2011 17:11:24 -0700 Message-ID: <4D757429.20108@linux.vnet.ibm.com> Date: Mon, 07 Mar 2011 18:11:21 -0600 From: Michael Roth MIME-Version: 1.0 References: <1299528642-23631-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D755190.6020101@us.ibm.com> <4D7560DF.6000404@linux.vnet.ibm.com> <4D756287.2060005@us.ibm.com> In-Reply-To: <4D756287.2060005@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v7 00/16] virtagent: host/guest communication agent List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, qemu-devel@nongnu.org, Jes.Sorensen@redhat.com, abeekhof@redhat.com On 03/07/2011 04:56 PM, Anthony Liguori wrote: > On 03/07/2011 04:49 PM, Michael Roth wrote: >> It's not really inventing anything. We've always started off with >> qobject params, which we then pulled apart and stuck into xmlrpc >> params, which when then turned into xml for transport. Now we just >> take the qobjects and covert them to json directly. We've only cut out >> an intermediate library and switched to a different UTF8-based >> encoding for transport. >> >> With QAPI we'd have the extra step of pulling function parameters into >> a qobjects. Not any different from what the situation would've been >> using xmlrpc or any of the other binary encoding that were considered. >> >> It does look more similar to what QMP/QAPI is doing than previously, >> but it doesn't need to be all or nothing. > > I think I have a Clever Idea here but hacking together a prototype. > > Basic thinking is to make guest commands part of the QMP namespace such > that a guest command looks like any other QMP command. The only role > QEMU plays in this model is validating the commands inputs and outputs > and then passing the command to the guest agent. Hmm...this does sound nice. But keep in mind that not all parameters passed in via QMP were intended solely for the guest. That just happens to be the case for the RPCs we have implemented in this RFC. For instance, one of QMP commands we intended to add for the new getfile implementation, to address concerns over a hardcoded file size limit while avoiding large memory allocations on the host or guest, was chunked file transfer using a set of stateful RPCs, with a higher level QMP command to wrap them: qmp.getfile Where could be a normal file, or "-" for direct output to monitor. Internally, the set of actual RPCs being executed are much lower level. Something like: offset = 0 local_fd = open() remote_fd = va.open() while (((read_count, buf) = va.read(remote_fd, offset, 512*1024)) > 0): write(local_fd, buf, read_count) offset += read_count va.close(remote_fd) Any higher-level commands of this type would be still doable, but would need to be pushed all the way up to the management stack, or done programatically, so it does limit what can be done within an interactive shell. Some might argue that's for the best, but there may be more of a trade-off in other possible use cases. > > Stay tuned. > > Regards, > > Anthony Liguori > >> >>> >>> Regards, >>> >>> Anthony Liguori >>> >> >