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

Re: [XEN PATCH 1/7] xen: introduce XENFEAT_xenstore_late_init


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 11 Jan 2022 08:14:29 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=RA8OEqcZNMHPSENVQPo9047qeVa8zMHzMn+l7773h6k=; b=F9jbEaC44uKqaSHgXOfdxqQNtfg6gpcbFGXR0JiQhw2hWBuE9P7JeuP9xZpFVjLEw6nin3hu46pb38M9anHLUzp44BDZAC4ftSXO+hLreq4gB5KVhsp1CHnQuAUq3Xu9N8AMqzv2MkFbcU8ni/xfXbTHTxb6kDZaBMzwxx4OAf+6/GSRVhbbAhfE1oiVgGdCzwiYyJz7+7MfMg6kjuNK9rZ4DTluPtxmno0IRUBhkHATlny8zddaI0MaZmkvBs2WHocqBMvjao+aFytpIQ8UcliM9er3ocN96mRYd/bESO8ySO58K3DpTIc1WV4og20qXWEMcw2hJxigDJZZGAkQyg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aXg5/mepHG7flNSMQU0GGFIj4DgOFeLz92jreGOiTPPQ0TKJu9VyYf14tIvEX1JYpfJaXajJyghHbCVBIFHlk3jSANC5P6XOtaXBlY2vfM9TP6A5nIWEtjAtgbh6B6GxxLQOr1jth7tCq3cVJlvoV6oMqHaiTNjmhrJB1Hqdk29TZgRlZgq4xvU44ESsFYvQuPXTWl4af0uoj8coN4+DAgtUwTLoF9Ab5+xI12s0RtAjQor/mt7A/QSHnrlKVS0EvBEr0/iXaMT6TsILNKCrpcgSB5tFtL/qp1oKf7ftiVssfj+6Q8LBJ8XPnjkbFRe6nbvGhvblugrp5u65wFIjpg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: julien@xxxxxxx, Bertrand.Marquis@xxxxxxx, Luca Miccio <lucmiccio@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 11 Jan 2022 07:14:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 11.01.2022 00:08, Stefano Stabellini wrote:
> 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.

Just as an aside - as discussed in some other context not so long ago,
HVM_PARAM_*_PFN being zero isn't the best way of expressing "not yet
initialized", and hence you would also want to check against ~0.

> But either way as far as I can tell we need to add a new check to delay
> xenstore initialization in Linux/HVM.

Yes, I can see that a Linux side change might be needed. But isolating
the change to there will be much better than needing to also have a
Xen side change in place.

Jan




 


Rackspace

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