From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44419 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pq51R-0004ax-51 for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:39:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pq51Q-0000Yz-6P for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:39:57 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:52124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pq51P-0000Uu-V2 for qemu-devel@nongnu.org; Thu, 17 Feb 2011 09:39:56 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1HETTro009705 for ; Thu, 17 Feb 2011 07:29:29 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1HEdm3U114364 for ; Thu, 17 Feb 2011 07:39:48 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1HEdlP6031753 for ; Thu, 17 Feb 2011 07:39:47 -0700 Message-ID: <4D5D3331.1000707@linux.vnet.ibm.com> Date: Thu, 17 Feb 2011 08:39:45 -0600 From: Michael Roth MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D5BF581.3050803@redhat.com> <4D5C07CB.4040709@linux.vnet.ibm.com> <4D5CDBD0.2060900@redhat.com> In-Reply-To: <4D5CDBD0.2060900@redhat.com> 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: Jes Sorensen Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino , aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, abeekhof@redhat.com On 02/17/2011 02:26 AM, Jes Sorensen wrote: > On 02/16/11 18:22, Michael Roth wrote: >> We've seen similar behavior. I think it comes down to qemu-va being >> linked against shared objects in the host that don't necessarily >> coincide with what's in the guest. It's somewhat misleading that we >> currently build qemu-va along with the binary, since qemu-va is not >> meant to be used on the host, and the version built on the host is not >> meant to be used in the guest. >> >> Really the guest binary, qemu-va, should be built in a proper build >> environment for that particular guest. Long term it may make sense to >> have a "guest-utils" target that isn't part of the normal host-build >> process to reflect binaries with these kinds of requirements. For now I >> think we'll may just end up removing qemu-va from the default make >> target, and only build it explicitly with "make qemu-va". > > Hi Michael, > > I am not sure I was totally clear in my mail, but the crashes I saw were > QEMU on the host that went down. Not qemu-va running in the guest. My Sorry, selective reading on my part. Had recently been tracking down issues on the guest side. > worry is that we are adding a lot of complexity into QEMU on the host > side which is going to be difficult to audit, especially with things > like the HTML and XML processing. If we separated host side processing > into a separate command, we could better protect ourselves against a > situation where a rogue guest could kill QEMU and possibly exploit it on > the host side. I think we should seriously look at moving the agent > processing code out of main QEMU and into a standalone command, maybe > qemu-va-host or something like that. I don't think the problem is really so fundamental...if you saw a host-side crash it's most likely a bug/sloppy error-handling in virtagent. Malformed xml (from version mismatches, transports errors, etc) shouldn't crash xmlrpc-c... it's using a libxml parser that just returns an error on unexpected xml...we just need to make sure we handle errors appropriately. Can you provide some details on what you ran and what the error message was? > > There has been talk about doing the same thing with the monitor in the > past, and have it talk to the main QEMU process over QMP. This pretty > much goes along the same lines, except that I think we need the XML > handling moved out with it, so we couldn't just layer it directly on top > of QMP. I've reworked the code quite a bit so that we could potentially swap out the xmlrpc-c layer transparently, while retaining the same HMP/QMP commands/formats. A very realistic thing we can consider in the future is using QMP for data encapsulation in place of xmlrpc, so I'd prefer not to drastically change the design to work around dependencies for the current data encapsulation scheme. Especially considering that terminating the protocol within QEMU, at the HMP/QMP layer, is one of the key benefits that differentiates virtagent from other guest agent proposals. But I think this is all a bit of a tangent if what we have here is just a virtagent bug. > >> P.S. Hoping to have the execute-RPCs-in-seperate-threads work done soon >> so we can get back to integrating your patches. > > Sounds good! > > Cheers, > Jes