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."):
> libxenvchan_server_init is asynchronous.

I went to look and I think what you mean is that it is fast.  Ie, it
does not need to wait for anything.

> libxenvchan_client_init is too,
> but it fails if called before server is ready.

That is less good.

> I have a
> wrapper[1] around libxenvchan_client_init in Qubes code which solve this
> problem with xs_watch. "libvchan: create xenstore entries in one
> transaction" patch is related to that wrapper.

Ah, yes, I saw that, I think it should go in soon if it hasn't
already.

> Maybe it should be also added to libxenvchan? Right now it only waits
> (synchronously) for server to appear (using while(...) xs_read_watch()).

That's rather poor.

> This is slightly more complex, as it also handle remote domain death
> before establishing connection as well qas save+restore local domain.
> But it can be provided as a separate function like
> libxenvchan_client_wait_for_server or such.

AIUI you would want to call such a function in libxl, because your
qemu stubdom is the server ?  In which case a synchronous call is no
good, because it would allow a rogue linux stubdom to block the entire
libxl process.

> Providing a function that could be used in libxl would be more complex,
> as it needs to integrate with libxl async API.

Oh, you're ahead of me.

> Maybe it could use
> good old trick with separate thread + pipe() for signaling readiness?

libxl has code for waiting for xs watches and domain death and so on
already.

How about this: provide a new variant of libxenvchan_client_init which
can give a return indication of the form `this server does not appear
to be set up; please watch on the following xenstore key and then call
me again when the watch fires'.  That would be simple, and not involve
further event loop entanglement, and would fit nicely into libxl.

> This way, the libxenvchan_client_wait_for_server would start separate
> thread (using own xenstore connection) and return fd that libxl can wait
> on. No need to convert libxenvchan_client_wait_for_server into callback
> hell...

That may be overkill.

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

Sounds complicated.  I think that is what your console state stuff is
about...

> > 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.
> 
> Well, I do that already (for pci-ins). In bash.

hahahaha.  Well, I think vchan may be easier.

Regards,
Ian.

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