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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B2DF0C433EF for ; Mon, 10 Jan 2022 23:09:18 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.255571.437978 (Exim 4.92) (envelope-from ) id 1n73mY-0008Kf-A9; Mon, 10 Jan 2022 23:08:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 255571.437978; Mon, 10 Jan 2022 23:08:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n73mY-0008KY-6z; Mon, 10 Jan 2022 23:08:54 +0000 Received: by outflank-mailman (input) for mailman id 255571; Mon, 10 Jan 2022 23:08:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n73mW-0008KS-H7 for xen-devel@lists.xenproject.org; Mon, 10 Jan 2022 23:08:52 +0000 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 462c6af4-726a-11ec-81c1-a30af7de8005; Tue, 11 Jan 2022 00:08:51 +0100 (CET) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CCF4FB8180F; Mon, 10 Jan 2022 23:08:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AD7DC36AE9; Mon, 10 Jan 2022 23:08:49 +0000 (UTC) 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: 462c6af4-726a-11ec-81c1-a30af7de8005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641856129; bh=J+uHqL/3GVypszrOXBTSHfj7KMFXMdTgutDTOMSr8PI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hZReYH6rvXjdrcLoBCxX4CC2xYSZhELVOJ7T/0Fd/V0LHybYlAU1ADdBqzW/4GGuW Bp11+co0bnydQSUgR4tWOi8uPTw6it8rfWnjvJV6MocXPMZaopuSYD47Vn6vUVtPj6 gnGMd6DPlecDGiPIfgxnzPESpclkEiYIackqjr3PvPlMTZaEXLYIUkJgvY//NV2orq W6HwT0n/xzue7XCBYC6mGRfO836cu4q55vB7v485mvaEoBN9oK/c8tQIwbdL0DUv0K ytpoq9+ZuUGkkxR90dnGwaozFnD+KXtmjcOo7fdipiqnoqzR7/iFNK9o2VgK972b3i 9N6XIMHHfD8XQ== Date: Mon, 10 Jan 2022 15:08:47 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , julien@xen.org, Bertrand.Marquis@arm.com, Luca Miccio , Stefano Stabellini , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 1/7] xen: introduce XENFEAT_xenstore_late_init In-Reply-To: Message-ID: References: <20220108004912.3820176-1-sstabellini@kernel.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 10 Jan 2022, Jan Beulich wrote: > On 08.01.2022 01:49, Stefano Stabellini wrote: > > Introduce a new feature flag to signal that xenstore will not be > > immediately available at boot time. Instead, xenstore will become > > available later, and a notification of xenstore readiness will be > > signalled to the guest using the xenstore event channel. > > In addition to what Julien has said, I'd like to point out that Linux'es > xenbus driver already has means to deal with xenstored not being around > right away (perhaps because of living in a stubdom which starts in > parallel). I therefore wonder whether what you want can't be achieved > entirely inside that driver, without any new feature flag. The fewer changes to Linux the better but we couldn't find a way to make it work with zero changes. In a way, the patch for Linux is re-using the existing infrastructure to delay initialization, e.g. xenbus_probe_thread to call xenbus_probe later. However, today there is nothing stopping Linux/HVM to continue initialization immediately except for xs_hvm_defer_init_for_callback which is not applicable in this case. So we introduced XENFEAT_xenstore_late_init. As I wrote in another reply, I think we could do without XENFEAT_xenstore_late_init if we instead rely on checking for HVM_PARAM_STORE_EVTCHN being valid and HVM_PARAM_STORE_PFN being zero. But either way as far as I can tell we need to add a new check to delay xenstore initialization in Linux/HVM.