From nobody Thu Apr 25 17:55:36 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=none dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1572524325; cv=none; d=zoho.com; s=zohoarc; b=Qap21dRoOskjCcDyaindRM1/BW/Fg6zre/tMdvtKrnroO/cK/Vg4zHpKSsI7VEyzJmHacfm0A9HSvz2AMw53LwJF4Earjpa4Yb9sfh10YPjJV5Trf3i5IsrUzWQkIYvqdefamXEwfw4ncmlX58h/AWq3pz7y79E3NHjSLtjGDBw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1572524325; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=irTSue45ADK3mQtMUH7Xllo9dvOBmvSgmLjo0J9XRmk=; b=UGnZsagFVWtewZNnXjha5fkfq1xsnUQk9cvHWJlXGBjp2/p6pVvTSgfWlmA9oL9seghSNSGl6vRntffIT6/o+j34TVVblh9q6G/ay4W6ginTf9FbdtuZDnqgSrR6PsTkU+GsPLOUulQaIC8Z7k436cBRNbmPX6srmRI3hFnQU4s= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=fail; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1572524325433513.9558906770642; Thu, 31 Oct 2019 05:18:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iQ9OQ-0006EA-1z; Thu, 31 Oct 2019 12:17:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iQ9ON-0006E5-Rs for xen-devel@lists.xenproject.org; Thu, 31 Oct 2019 12:17:31 +0000 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 68cc5d08-fbd8-11e9-9540-12813bfff9fa; Thu, 31 Oct 2019 12:17:30 +0000 (UTC) X-Inumbo-ID: 68cc5d08-fbd8-11e9-9540-12813bfff9fa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1572524251; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=r0sT7HPdF/WzdFKV28CDTGc+ITnNW4iu60pHK+4sJkE=; b=LQFpRY7x8qHmR6odK6qKj7Tz1GrDHTKY1dTahmNODUjaF7feRdE44GNj VmYHRTn0qbr8OvNe4w1o5PiQwFQI24ESGxPcwCBpHziQ2hk45YjkuEuhM v9NvbVTKlbI0Je77oLtvk8Cg2QYzBFX9L6oY7ZRUd/UuQKMUH9Jlb8RcY 4=; Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@citrix.com; spf=Pass smtp.mailfrom=anthony.perard@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender authenticity information available from domain of anthony.perard@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa1.hc3370-68.iphmx.com: domain of anthony.perard@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="anthony.perard@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa1.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa1.hc3370-68.iphmx.com; envelope-from="anthony.perard@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: zzqy6fRnY7bm1txhI8+IUjaf1d6XavIjSoSx9TQv3pa03OAEeCfaWKDEkLPZTzZdZIkrBip+xd mOKx1/ytvuIrmqfxNKH8Ws79JP0GcvdYFse+JSeJtml7A1q0jHgJwbpI34J818Es7p3gKj7bcz +pZGRWv4r+mhbHN5VgsvlqqEBhynBGt1yMso+i+/trDzEPIwFKIu3KVNqEfG8bRffIrjekmz+k Veoqnjt1L/jyt2qJuFr14SwhilDHDLGWzhO6zFsYKQBi6Ilii1ubNaKCkKqmMiic5VREpX+Fdy vno= X-SBRS: 2.7 X-MesageID: 7774296 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.68,250,1569297600"; d="scan'208";a="7774296" From: Anthony PERARD To: Date: Thu, 31 Oct 2019 12:17:27 +0000 Message-ID: <20191031121727.287419-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Subject: [Xen-devel] [XEN PATCH for-4.13] libxl_pci: Don't hold QMP connection while waiting X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Anthony PERARD , Ian Jackson , Wei Liu Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) After sending the 'device_del' command for a PCI passthrough device, we wait until QEMU has effectively deleted the device, this involves executing more QMP commands. While waiting, libxl hold the connection. It isn't necessary to hold the connection and it prevents others from making progress, so this patch releases the QMP connection. For background: e.g., when a guest is created with several pci passthrough attached, on `xl destroy` all the devices needs to be detach, and this is usually what happens: - 'device_del' called for the 1st pci device - 'query-pci' checking if pci still there, it is - wait 1s - 'query-pci' checking again, and it's gone -> now the same can be done for the second pci device, so plenty of waiting on others when pci detach can be done in parallel. On shutdown, libxl usually keeps waiting because QEMU never releases the device because the guest kernel never responds QEMU's unplug queries. So detaching of the 1st device waits until a timeout stops it, and since the same timeout is setup at the same time for the other devices to detach, the 'device_del' command is never sent for those. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index b5444d15523a..3262c2952baa 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -2061,6 +2061,8 @@ static void pci_remove_qmp_query_cb(libxl__egc *egc, =20 if (rc) goto out; =20 + libxl__ev_qmp_dispose(gc, qmp); + asked_id =3D GCSPRINTF(PCI_PT_QDEV_ID, pcidev->bus, pcidev->dev, pcidev->func); =20 --=20 Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel