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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel