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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

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).

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?).

(...)

> 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?

> [1] 
> https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qmp-spec.txt;h=8f7da0245d51447be7df2b3d4b105bad9fbec0b3;hb=HEAD#l231

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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