From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rumny-0000bN-N7 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 10:18:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rumnr-0007K2-O7 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 10:18:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rumnr-0007In-Dd for qemu-devel@nongnu.org; Tue, 07 Feb 2012 10:17:55 -0500 Message-ID: <4F314086.4040109@redhat.com> Date: Tue, 07 Feb 2012 16:17:26 +0100 From: Michal Privoznik MIME-Version: 1.0 References: <1328576953-19701-1-git-send-email-mdroth@linux.vnet.ibm.com> <1328576953-19701-2-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1328576953-19701-2-git-send-email-mdroth@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Michael Roth Cc: libvir-list@redhat.com, qemu-devel@nongnu.org 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? Michal