From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36845 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwkja-0002Ko-3E for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:25:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwkjY-0007Rf-Pl for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:25:05 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:54598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwkjY-0007RU-Gr for qemu-devel@nongnu.org; Mon, 07 Mar 2011 19:25:04 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2809xUS000900 for ; Mon, 7 Mar 2011 17:09:59 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p280P3Ri113606 for ; Mon, 7 Mar 2011 17:25:03 -0700 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 p280P2Yg018799 for ; Mon, 7 Mar 2011 17:25:03 -0700 Message-ID: <4D75775B.5020309@us.ibm.com> Date: Mon, 07 Mar 2011 18:24:59 -0600 From: Anthony Liguori 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> <4D757429.20108@linux.vnet.ibm.com> In-Reply-To: <4D757429.20108@linux.vnet.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: Michael Roth 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 06:11 PM, Michael Roth wrote: > 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: Just as HMP commands can be implemented in terms of QMP commands, QMP commands can be implemented in terms of QMP commands. Regards, Anthony Liguori > > 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 >>>> >>> >> >