On 24/01/2019 13:29, Anthony PERARD wrote: > Since libxl later during guest creation run the command "cont", it kind > of expect that QEMU would not do any emulation, use the "-S" command > option to make this effective. Unfortunately, when QEMU is started with > "-S", it won't write QEMU's readiness into xenstore. So only activate > this options when we have a QEMU startup notification via QMP available, > which is when dm_restrict is activated. > > This have the side-effect of rendering ineffective the startup > notification via xenstore, libxl will only have the notification via > QMP. > > It became important to rely only on QMP for notification when we have > it, as cutting short that path may result in the QMP socket been blocked > and have QEMU stop responding to upcoming connection even if none are > active. > > The QEMU bug that this patch works around is: > - libxl connect and hand-check with QEMU, then send the cmd > "query-status". > - QEMU prepare and maybe try send the response, > while also writing "running" into xenstore. > - libxl see via xenstore that QEMU is running and disconnect from the > QMP socket before receiving the response the cmd. > => The QMP socket (monitor) is sometime blocked and will never reply > to commands on new connections. > > This is due to QEMU only responding to one command at a time, and > suspending its monitor (QMP) until the command as been processed and > sent. Disconnecting from the socket doesn't unsuspend the monitor. The > race described here is very likely to happen with QEMU 3.1.50 (during > 3.2 development), but can be reproduced with QEMU 3.1. > > Signed-off-by: Anthony PERARD <anthony.per...@citrix.com>
Release-acked-by: Juergen Gross <jgr...@suse.com> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
