Re: [libvirt] [Qemu-devel] [PATCH v2] qemu-ga: add guest-sync-delimited
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(a)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