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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3256 bytes --]

On Fri, Nov 16, 2018 at 10:39:07AM +0000, Anthony PERARD wrote:
> 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.

It may be tricky to figure out where is the end of such incomplete json
object... Suppose you read:

{ "x": { "y": 1 } } }

If you read this from the beginning looking for json, you'll get valid
json object unless you encounter the last "}" (which you may receive in
separate read() call, if you're unlucky). I'm afraid the logic for
skipping initial (possibly incomplete) object(s) may be quite complex.
Maybe better propose upstream to include 'guest-sync-delimited' also on
monitor socket too? In that case, the command naming will be awkward,
but still, similar command would be useful in that context.

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

That's good.

-- 
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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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