From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACE83C43460 for ; Tue, 27 Apr 2021 00:24:00 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4B5716101C for ; Tue, 27 Apr 2021 00:24:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B5716101C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.117946.223887 (Exim 4.92) (envelope-from ) id 1lbBW0-0007r6-19; Tue, 27 Apr 2021 00:23:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 117946.223887; Tue, 27 Apr 2021 00:23:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lbBVz-0007qw-Tu; Tue, 27 Apr 2021 00:23:47 +0000 Received: by outflank-mailman (input) for mailman id 117946; Tue, 27 Apr 2021 00:23:46 +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.92) (envelope-from ) id 1lbBVy-0007mO-IG for xen-devel@lists.xenproject.org; Tue, 27 Apr 2021 00:23:46 +0000 Received: from out1-smtp.messagingengine.com (unknown [66.111.4.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8e946aa0-51b7-41c1-ac44-77d88261096f; Tue, 27 Apr 2021 00:23:37 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 798F45C017C; Mon, 26 Apr 2021 20:23:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 26 Apr 2021 20:23:37 -0400 Received: from localhost.localdomain (ip5b434f04.dynamic.kabel-deutschland.de [91.67.79.4]) by mail.messagingengine.com (Postfix) with ESMTPA id BAAD6108005F; Mon, 26 Apr 2021 20:23:36 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e946aa0-51b7-41c1-ac44-77d88261096f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=c2QDLs+tJ379utFzbl/w+Nqe4CBOem8f00hNMpbEn bU=; b=AJXJHgSOQcqW0r01N3LcHa4VJa1gE4dtvghNkuJbrgkVZiecPzGKXSY/+ oCNM8kkzWcyyRfLg6xU7BUvLVZrWanIVNnXR4XPhT9Ospu+xOaxLE0CaYQHiKVGF hUjwR1ZcqKitWWxdKH5DmpViUCzinSivzI4K88vfsz/85YYJ3j2gD/hiC3s6EqPV Bv2510pdw0ap/aYRyFEmNrIYGMF6zWoPBCOl9bQWX5soNNDcGCtfESP9Z1iDaAF+ ygYtINZ68CNlibKCL0f2WLklhkO+4n1eijQ7bQznq7d5NLa9Rkx//vK4iRw/NNLQ wrvMBLtvjneE/ZSCoXbO2yuU40VRA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdduledgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinh hvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfei ueethfeivdetffetueeftdeileeiteeiudefveeugedvfeeggeeiudekteeunecuffhomh grihhnpehpohgurdhinhenucfkphepledurdeijedrjeelrdegnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Ian Jackson , Wei Liu , Anthony PERARD Subject: [RFC PATCH 2/2] libxl: allow to skip block script completely Date: Tue, 27 Apr 2021 02:22:32 +0200 Message-Id: <25fbb81f8f7805a390613521dadedaeab4cd4563.1619482896.git-series.marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Default block script is quite slow and requires global lock which slows it down even more (for domains with multiple disks). The common case of a block device-based disk is trivial to handle and does not require locking. This can be handled directly within libxl, to avoid slow script execution and waiting for it to finish. This, depending on the hardware, may save about 0.5s of domain start time per disk. Allow setting script name to empty string to skip executing the script at all, and use target name as a block device path directly. This does skip two functions of the block script: - checking if device isn't used anywhere else (including mounted in dom0) - setting up loop device for a file-based disk The former is expected to be done by the operator manually (or by a higher level management stack, that calls into libxl). The later is a limitation of the current implementation, but should be possible to extend in the future. The code to fill 'physical-device' xenstore node is added via libxl__hotplug_disk() (in libxl_linux.c) intentionally. This code is called in device backend domain (which may be not dom0), contrary to device_disk_add() which fills all the other xenstore entries, but is called always in the toolstack domain (dom0). libxl__hoplug_disk() is called from libxl__get_hotplug_script_info(), which may not sound like the most logical place to actually change some state, but it is called when we need it. Signed-off-by: Marek Marczykowski-Górecki --- docs/man/xl-disk-configuration.5.pod.in | 4 ++- tools/libs/light/libxl_disk.c | 7 ++- tools/libs/light/libxl_linux.c | 62 ++++++++++++++++++++++++++- 3 files changed, 71 insertions(+), 2 deletions(-) diff --git a/docs/man/xl-disk-configuration.5.pod.in b/docs/man/xl-disk-configuration.5.pod.in index 71d0e86e3d63..3b3b3c329e13 100644 --- a/docs/man/xl-disk-configuration.5.pod.in +++ b/docs/man/xl-disk-configuration.5.pod.in @@ -261,6 +261,10 @@ information to be interpreted by the executable program I