From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42389 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pq0cW-0007PM-Mv for qemu-devel@nongnu.org; Thu, 17 Feb 2011 04:57:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pq0cV-0001yd-JX for qemu-devel@nongnu.org; Thu, 17 Feb 2011 04:57:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pq0cV-0001yY-Cv for qemu-devel@nongnu.org; Thu, 17 Feb 2011 04:57:55 -0500 Message-ID: <4D5CE57E.4040508@redhat.com> Date: Thu, 17 Feb 2011 11:08:14 +0200 From: Dor Laor 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 Reply-To: dlaor@redhat.com 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, Michael Roth , aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, abeekhof@redhat.com, Luiz Capitulino On 02/17/2011 10: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 > 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. +1 Qemu will fork this qemu-va-host process so it won't be an extra burden on the management, qemu and his son should talk over pipe, passing the qmp commands to it. > > 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. > >> 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 >