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 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]:

  2.7 QGA Synchronization
  -----------------------

  When a client connects to QGA over a transport lacking proper
  connection semantics such as virtio-serial, QGA may have read partial
  input from a previous client.  The client needs to force QGA's parser
  into known-good state using the previous section's technique.
  Moreover, the client may receive output a previous client didn't read.
  To help with skipping that output, QGA provides the
  'guest-sync-delimited' command.  Refer to its documentation for
  details.

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.

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

-- 
Anthony PERARD

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