Re: [Xen-devel] [RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround, multiple connection to single QMP socket

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Hi.  Thanks for tackling this swamp.  All very unfortunate.

Anthony PERARD writes ("[RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround, 
multiple connection to single QMP socket"):
> Alternatively to this craziness, it might be possible to increase
> the `backlog' value by having libxl opening the QMP socket on behalf
> of QEMU. But this is only possible with a recent version of QEMU
> (2.12 or newer, released in Apr 2018, or qemu-xen-4.12 or newer). It
> would involve to discover QEMU's capability before we start the DM,
> which libxl isn't capable yet.

I have an ancient unapplied patch somewhere which runs qemu --help
and greps the output.  If you would like, I can dig it out.

But one problem with that approach is this: without that feature in
qemu, what would we do ?  Live with the bug where domain creation
fails ?  Bodge it by serialising within domain create (awkwardating
the code) ?

I have some other suggestions which ought to be considered:


1. Send a patch to qemu upstream to allow specifying the socket listen
queue.

1(a) Expect distros to apply that patch to older qemus, if they ship
older qemus.  Have libxl unconditionally specify that argument.

1(b) grep the help output (as I propose above) and if the patch is not
present, use LD_PRELOAD to wrap listen(2).


2. Send a patch to qemu upstream to change the fixed queue length from
1 to 10000.  Expect distros to apply that patch to older qemus (even,
perhaps, if it is not accepted upstream!)  Change libxl to detect
EAGAIN from qmp connect() and print a message explaining what patch is
missing.


Since you have provided an implementation of the fork/lock strategy,
I'll now go and do a detailed review of that.

Thanks,
Ian.

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