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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for 
qemu-xen runnning in a Linux-based stubdomain."):
> All the xenconsoled stuff is unchanged (and unlikely to change), so it
> should be safe to review it. Patches 06 and 07 also shouldn't change.

Sorry, I missed this reply.  I will go on to review those.

> The thing that will change is qemu cmdline and qmp handling. TBH I'm not sure
> if its better to touch qmp now, or after reworked qmp handling by
> Anthony will be merged. There will definitely be some conflicts and it
> may even affects what underlying mechanism is chosen for qmp transport.
> Based on discussion here, and in libxl__ev_qmp_* thread, I see two
> viable options:
> 
> 1. libvchan
>   pros:
>    - out of band reset support, so qmp capabilities negotiation can be
>      handled gracefully
>   cons:
>    - more work, require patching qemu (or adding vchan->socket proxy),
>      adds dependency on libvchan to libxl (probably not a problem)
>    - possibly more complex libxl__ev_qmp_* handling, or at least needs
>      separate handling of send/receive for stubdomain case

I think that the changes to libxl__ev_qmp_* will be relatively
self-contained, particularly after Anthony's async rework.  There's
one place where the communication occurs.

Does libvchan offer asynchronous connection (ie, connect/disconnect
calls which cannot be stalled by the peer, but which instead allow
poll/select-based async) ?  I think it may not, in which case we need
a vchan to socket proxy anyway.

Aside from that the libxl dependency is untroublesome.

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

>    - possibly other problems from that (events filling up some buffers
>      when no one is listening?)

xenconsole drops things in this situation.  I think that may result in
desynchronisation.

> BTW Does libxl listed for qmp events?

Not right now.  It may want to in future.  Anthony's qmp series
discards events.

> There is also third option: xenstore, but that would probably require
> totally separate libxl__ev_qmp_* implementation, so I'd rule it out.

That's not a terrible idea but I can't see it being popular with qemu
upstream, so you'd end up writing a kind of bidirectional
qmp<->xenstore proxy.  Urgh.

> If problems with pv console could be solved, I'd go this way. But
> otherwise libvchan seems like a good alternative.

Yes.

Ian.

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