From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59948 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwxit-0003d0-I6 for qemu-devel@nongnu.org; Tue, 08 Mar 2011 09:17:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwxis-0001hC-3k for qemu-devel@nongnu.org; Tue, 08 Mar 2011 09:17:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwxir-0001g7-Hf for qemu-devel@nongnu.org; Tue, 08 Mar 2011 09:17:13 -0500 Message-ID: <4D763A61.2020809@redhat.com> Date: Tue, 08 Mar 2011 16:17:05 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1 References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <4D7500C8.1080101@codemonkey.ws> <4D760F2B.7030004@redhat.com> <4D7630BA.4010609@us.ibm.com> <4D763311.5030905@redhat.com> <4D763525.2030700@codemonkey.ws> <4D763674.8000600@redhat.com> <4D7638BE.60808@codemonkey.ws> In-Reply-To: <4D7638BE.60808@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Luiz Capitulino , Adam Litke , Markus Armbruster , qemu-devel@nongnu.org On 03/08/2011 04:10 PM, Anthony Liguori wrote: > On 03/08/2011 08:00 AM, Avi Kivity wrote: >> On 03/08/2011 03:54 PM, Anthony Liguori wrote: >>> >>>> (and gah, do we really need a vfs/rpc in qemu?) >>> >>> Fun, eh :-) Unfortunately, our friends at VMware provide a >>> VixVM_CopyFileFromGuestToHost API so there's an expectation that we >>> provide a similar interface. >>> >> >> Yes, but do we have to terminate it in qemu? > > No, I'm in the process of writing up my latest proposal. > > The idea is pretty simple. QAPI generates code for libqmp that takes > native arguments for a command and generates a QObject. It also > generates code for QEMU that takes a QObject and generates native > arguments to pass to a function. > > For guest commands, we combine the two such that we unmarshal the > incoming QObject to native arguments, then pass it to another function > that marshals the arguments to a QObject. The QObject is then passed > to the guest-agent which uses the same generated code as QEMU to > unmarshal the qobject to native arguments and dispatch to a function. > > That means the only new code we need for the guest agent is the > JSON-over-virtio-serial transport. To implement guest commands, we > just add the command to the schema, implement the native arguments > version in guest-agent, and that's it. > > QEMU will buffer all input and output to the guest acting as a first > line of defence from a security PoV. That means that the guest > doesn't get to talk directly to the management tools which removes > that as a direct attack surface. > > The nature of QEMU is such that if we do tagging correctly, we can > also support live migration transparently to the guest too. Okay, do I understand correctly that qemu does not understand each command individually? It just reads the schema and converts from one rpc protocol to another (even if they are the same protocol)? So: mgmt -> json -> qemu -> (qobject -> ) json -> guest (and back again). If that's the case, I like it. -- error compiling committee.c: too many arguments to function