From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuoCv-0007cf-Mo for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:47:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuoCo-0003ar-Vv for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:47:53 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:59948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuoCo-0003aZ-RA for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:47:46 -0500 Received: by pbaa11 with SMTP id a11so8076992pba.4 for ; Tue, 07 Feb 2012 08:47:46 -0800 (PST) Sender: fluxion Date: Tue, 7 Feb 2012 10:47:39 -0600 From: Michael Roth Message-ID: <20120207164739.GA21191@illuin> References: <1328576953-19701-1-git-send-email-mdroth@linux.vnet.ibm.com> <1328576953-19701-2-git-send-email-mdroth@linux.vnet.ibm.com> <4F314086.4040109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F314086.4040109@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-sync-delimited List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Privoznik Cc: libvir-list@redhat.com, qemu-devel@nongnu.org On Tue, Feb 07, 2012 at 04:17:26PM +0100, Michal Privoznik wrote: > On 07.02.2012 02:09, Michael Roth wrote: > > guest-sync leaves it as an exercise to the user as to how to reliably > > obtain the response to guest-sync if the client had previously read in a > > partial response (due qemu-ga previously being restarted mid-"sentence" > > due to reboot, forced restart, etc). > > > > qemu-ga handles this situation on its end by having a client precede > > their guest-sync request with a 0xFF byte (invalid UTF-8), which > > qemu-ga/QEMU JSON parsers will treat as a flush event. Thus we can > > reliably flush the qemu-ga parser state in preparation for receiving > > the guest-sync request. > > > > guest-sync-delimited provides the same functionality for a client: when > > a guest-sync-delimited is issued, qemu-ga will precede it's response > > with a 0xFF byte that the client can use as an indicator to flush its > > buffer/parser state in preparation for reliably receiving the > > guest-sync-delimited response. > > > > It is also useful as an optimization for clients, since, after issuing a > > guest-sync-delimited, clients can safely discard all stale data read > > from the channel until the 0xFF is found. > > > > More information available on the wiki: > > > > http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol > > > > Signed-off-by: Michael Roth > > This makes sense. And it's workable for libvirt. > IIUC, client can send 0xFF to the guest agent and vice versa, right? Yup, and it should be considered a requirement to send the 0xFF before guest-sync* to avoid some of the potential corner cases mentioned, since on the qemu-ga side the 0xFF reliance is baked in. Clients have a choice as to how they want to deal with this scenario so we offer both guest-sync (no 0xFF) and guest-sync-delimited (precede response with 0xFF). > > Michal >