From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STzlG-00004s-Re for qemu-devel@nongnu.org; Mon, 14 May 2012 14:12:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1STzlB-0003Nx-Mq for qemu-devel@nongnu.org; Mon, 14 May 2012 14:12:46 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:40869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STzlB-0003NX-FL for qemu-devel@nongnu.org; Mon, 14 May 2012 14:12:41 -0400 Received: by obbwd20 with SMTP id wd20so9523018obb.4 for ; Mon, 14 May 2012 11:12:39 -0700 (PDT) Sender: fluxion Date: Mon, 14 May 2012 13:12:35 -0500 From: Michael Roth Message-ID: <20120514181235.GE28865@illuin> References: <1336763987-10920-1-git-send-email-lcapitulino@redhat.com> <4FB13B94.4070903@redhat.com> <4FB13E1E.6010605@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB13E1E.6010605@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2]: qemu-ga: make shutdown & suspend synchronous List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Michal Privoznik , qemu-devel@nongnu.org, Luiz Capitulino On Mon, May 14, 2012 at 11:17:18AM -0600, Eric Blake wrote: > On 05/14/2012 11:06 AM, Michal Privoznik wrote: > > On 11.05.2012 21:19, Luiz Capitulino wrote: > >> The main motivation for this series is fixing two possible race conditions > >> in the guest-suspend-* API due to the complexity that arose from the way > >> we handle terminated children processes today. Full details in the first > >> patch. > >> > >> This series applies on top of my two other qemu-ga series submitted > >> previously: > >> > >> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00999.html > >> > >> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01507.html > >> > >> qapi-schema-guest.json | 56 ++++++++++------ > >> qapi/qmp-core.h | 10 ++- > >> qapi/qmp-dispatch.c | 8 ++- > >> qapi/qmp-registry.c | 4 +- > >> qemu-ga.c | 40 ++++++------ > >> qga/commands-posix.c | 162 ++++++++++++++++++---------------------------- > >> qga/guest-agent-core.h | 4 ++ > >> scripts/qapi-commands.py | 14 +++- > >> 8 files changed, 154 insertions(+), 144 deletions(-) > >> > > > > Okay, this is definitely an enhancement and fix of bogus implementation. > > One thing that I'd like to ask is - how can user distinguish between > > these implementations. I am asking basically from libvirt POV. > > Because if I assume I am dealing with the previous implementation and > > thus waiting for the {'return':{}} before I can return form an API, but > > the GA actually uses the new implementation I will block endlessly. > > I think the point was that you would block endlessly waiting for the > {'return':{}} anyways, even with the old implementation, because there > was no guarantee that the guest agent could issue the reply in a timely > manner. Therefore, the only sane implementation in libvirt is to assume > that success will not be reported via the guest agent, and that libvirt > must _always_ probe for the listed side effects (a change in guest > status, qemu exiting, an event, or so forth), and optionally have a > timeout if the associated timeout does not occur in a reasonable time. Additionally, *all* commands carry the risk that qemu-ga can die (killed, crashed, guest reboots, not being installed to begin with, etc) before issuing a response, so a timeout mechanism *must* be in place if it blocks libvirt. Let me know if it's unclear how timeout+reset is to be implemented/used. I've captured most of the ins/outs here but I realize it's still a bit of a headache: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol > > -- > Eric Blake eblake@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >