Re: [Qemu-devel] [PATCH v2] qemu-ga: add guest-sync-delimited

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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 <mdroth@linux.vnet.ibm.com>
> 
> 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
>