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@xxxxxxxxxxxxxxxxxx> > > 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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list