qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communi


From: Jes Sorensen
Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent
Date: Thu, 17 Feb 2011 09:26:56 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]