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

From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	julien@xen.org,  Bertrand.Marquis@arm.com,
	Luca Miccio <lucmiccio@gmail.com>,
	 Stefano Stabellini <stefano.stabellini@xilinx.com>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	 Andrew Cooper <andrew.cooper3@citrix.com>,
	 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
	 xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 1/7] xen: introduce XENFEAT_xenstore_late_init
Date: Tue, 11 Jan 2022 14:51:22 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2201111450070.19362@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <627242da-78e2-913f-33a4-4ae7fb94664a@suse.com>

On Tue, 11 Jan 2022, Jan Beulich wrote:
> 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.

Yes, good point

> > 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.

I agree. I managed to remove XENFEAT_xenstore_late_init from the patch
series and everything works fine. It will be in the next version.