[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] libxl: wait for QEMU exit before restarting a domain


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Jiaqing Zhao <Zhao.Jiaqing@xxxxxxx>
  • Date: Wed, 11 Nov 2026 13:51:52 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d83tCLT6ksUjT7bgelpDP2wmClPUG0KK4z1p3tA4E6s=; b=uAOaluxHZNCHgYFx+W/xX1Ti30qS/Y99C3g7dEYFmmNzPk7oVrh12ESC+ZU6neJ1KQtWb1eCNQm84Ed8n8utx97l/cHYNlP9CBHqcaLKIs3w0f0OVotYizXPEK1W99xwMTT32owWmhT7nV9JK+nokMQl6HEY6j5LjgzFrU1g0o/D7T8dIjAAjfeY5OoqvvLXbdaeYKJYxE/utTiHtj86PySlneYamILMaFxYQLu1TymdG6WC1DWQVjdIlnqJfd9JLEOkaZcuTOw9MPD+gpiJGvRzAkTIoBOV+hV/unASOIuq6pjIQPk+p9KhSSLLWAIBMpSu0fG9Gm57wcxcIroxPw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m86nZ8Ph0PDCFDTJTlOz195LFjMSZ4NqNiBLdW5yPMtg5CcSLx1E6dhoCwydUYLnS51N9onRT23UWqFlED1FzEm+9cSVbpKUVeMQikmzJ2j14CWl7F0nfuP4octRSkAzkotm/NMCDlfMGidXyFvSGN56fVFk/HC2+A8Fm1YssI71s5h/Le7lWGAOdVDYB1X5VzIF1AvjeSTXUI0ZCzGaqDtXK3fjxpkzwK7kgkzyIBo//xd+sVD4TojF+ysX6Vb8ASHeO+cyefb7MZ3mDKTSSZqnKdjwjfdUZKRh5I40NI6q8/XaKZjhB0/81xMmUKit2P4oeBMUyPOVZSFL/K6viw==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Penny Zheng <penny.zheng@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 11 Nov 2026 05:52:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 2026-11-10 18:22, Jan Beulich wrote:
> On 10.11.2026 11:02, Jiaqing Zhao wrote:
>> The PID-based device model destruction path returns immediately after
>> sending SIGHUP, before QEMU has necessarily exited. When an HVM guest
>> reboots with VNC enabled, the new QEMU process may fail to bind the VNC
>> port because the old process still holds it.
>>
>> Wait for QEMU to exit in a child process after signaling it for at most
>> 10 seconds. If waiting fails or times out, log the error and retain the
>> existing domain destruction behaviour.
>>
>> Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@xxxxxxx>
>> ---
>> v2:
>> * Share the fork, error handling and child exit handling between UID and
>>   PID-based destruction paths.
>> * Reduce the device-model stop timeout from 60 to 10 seconds.
> 
> As per my v1 comments I continue to question this.

I looked further into QEMU's shutdown path. After receiving SIGHUP,
QEMU calls bdrv_drain_all() to wait for outstanding block I/O requests
and bdrv_flush_all() to flush its block devices. These could take
longer than 10 seconds on slow storage.

While this does not identify the timeout you observed with SR-IOV,
my earlier measurements are insufficient to prove that 10s is enough.
I'll restore the 60s timeout in v3.

>> * Handle unexpected errors from kill(pid, 0) explicitly.
>> * Fix misspelled "signaling" in commit message.
>> * Coding style fixes against tools/libs/light/CODING_STYLE.
>> ---
>> Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> Cc: Juergen Gross <jgross@xxxxxxxx>
>> Cc: Roger Pau Monné <roger@xxxxxxxxxxxxxx>
> 
> You will want to use a correct address here (.org rather than .com).
> 
> Jan

That was my mistake, sorry.

By the way, on MAINTAINERS:390, Roger's address uses .com, maybe it need to
be fixed?



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.