Re: [Qemu-devel] Re: [RFC][PATCH v1 07/12] qmp proxy: core code for proxying qmp requests to guest

[Michael Roth]

On 03/28/2011 02:05 PM, Anthony Liguori wrote:
> On 03/25/2011 04:56 PM, Michael Roth wrote:
> > > I don't quite follow what this is doing.
> >
> >
> > That's for the session negotiation so we can reset state when the
> > guest agent restarts. The sequence is:
> >
> > guest -> host
> > { "_xport_event": "guest_init", "_xport_arg_sid": <random session id> }
> >
> > host -> guest
> > { "_xport_event": "host_ack", "_xport_arg_sid": <received session id> }
> >
> > Guest will ignore anything it gets until it sees an ack with the
> > proper session id, host will cancel outstanding requests when it
> > receives a guest init. If there's already an event waiting to be sent
> > we clobber it since for the above exchange only the most recent event
> > we sent matters.
> >
> > We send them as json objects, but they get handled at transport level
> > and terminate there.
>
> Doesn't an invalid UTF-8 sequence provide the same functionality?

We do use the invalid UTF-8 sequence here to some extent, but just to 
ensure the xport events are delivered intact. All xport events are 
preceded with 0xFF to make sure they delivered. After negotiation we 
assume everything is clear for standard json streaming.

We could use an invalid UTF-8 sequence by itself, but it would need to 
be paired with some mechanism to clear the channel, otherwise multiple 
guest agent restarts could result in an agent reading a "stale" ack from 
the host and proceeding to service canceled/invalid requests.

I think, at least with virtio-serial, a close() on the chardev would 
clear the channel...so that might work. That may not be the case with 
isa-serial though. Pairing the init/ack sequence with a session id just 
seemed a little more robust.

> Regards,
>
> Anthony Liguori