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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.