Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Thu, Nov 15, 2018 at 07:57:08PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 15, 2018 at 05:41:44PM +0000, Anthony PERARD wrote:
> > On Thu, Nov 01, 2018 at 06:32:07PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Nov 01, 2018 at 04:57:18PM +0000, Ian Jackson wrote:
> > > > Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add 
> > > > support for qemu-xen runnning in a Linux-based stubdomain."):
> > > > > 2. pv console
> > > > >   pros:
> > > > >    - no qemu modifications
> > > > >    - same read()/write() on libxl side
> > > > >   cons:
> > > > >    - no out of band reset, needs libxl handling for that (skipping
> > > > >      negotiation)
> > > > 
> > > > Doesn't this potentially mean that the qmp console connection can
> > > > become irrecoverably desynchronised ?  I don't know how you would
> > > > recover from the situation where another libxl process had got halfway
> > > > through some qmp stuff and been terminated (for whatever reason; maybe
> > > > the calling toolstack crashed).
> > > 
> > > That's right, it could result in irrecoverably desynchronised
> > > connection. So, we need out of band reset.
> > 
> > Actually, it looks like we can recover that situation without out of
> > band reset. It's even in the spec[1]:
> 
> That's interesting. And it mention serial console explicitly as the use
> case for this. Does it apply to monitor socket too, or guest agent only?
> I'd much prefer to use console, as the code would be much simpler (the
> same handling for local and stubdomain qemu).

The 'guest-sync-delimited' command doesn't seems to be available on the
monitor socket. I should have checked that ... but that would just mean
that libxl would need to tolerate the first read to be an incompleted
json-object. Then we can use the 'id' that every response have to figure
out if it was a reply sent to a previous libxl run. We can maybe encode
the pid into the id.

> Also, this doesn't cover capabilities (re-)negotiation. While actual
> capabilities are probably not a problem, libxl do store qemu version
> from the server greeting (is it used anywhere?).

The QEMU version is still available after the capabilities negociation,
one simply need to execute 'query-version'.

And yes, the version is used. So far there is one command that changes
with newer version of QEMU, 'xen-save-devices-state'.

> > previous section:
> >   2.6 Forcing the JSON parser into known-good state
> >   -------------------------------------------------
> > 
> >   Incomplete or invalid input can leave the server's JSON parser in a
> >   state where it can't parse additional commands.  To get it back into
> >   known-good state, the client should provoke a lexical error.
> > 
> >   The cleanest way to do that is sending an ASCII control character
> >   other than '\t' (horizontal tab), '\r' (carriage return), or '\n' (new
> >   line).
> > 
> >   Sadly, older versions of QEMU can fail to flag this as an error.  If a
> >   client needs to deal with them, it should send a 0xFF byte.
> 
> That's weird as guest-sync-delimiter documentation (still?) mention
> 0xFF. In both directions. Does it mean the new recommendation is to use
> ASCII control character in one direction, but expect 0xFF in the other?

Looks like it. But there is a different between the server and the
client, the server still parse JSON, but the client will actively look
for the delimiter once the command have been sent.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel