Re: Xen 4.18 release: Reminder about code freeze

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Fri, Oct 13, 2023 at 4:04 PM Juergen Gross <jgross@xxxxxxxx> wrote:
> >>> Technically, dom0 has exactly the same problem as dom0less domains it 
> >>> boots
> >>> before Xenstored is running and therefore it may need to know when it is
> >>> ready to receive commands.
> >>
> >> Umm, no, not really.
> >>
> >> The main difference between dom0 and a dom0less domU is, that xenstored
> >> introduces dom0 by itself via a call of dom0_init(), while the dom0less
> >> domUs get introduced by Xen tools in case a dom0 is coming up later. And
> >> that XS_INTRODUCE will clobber any ring page contents, while a call of
> >> dom0_init() won't do that.
> >>
> >> Dom0 (especially the kernel) is fine to start filling the ring page with
> >> requests even before xenstored is running. It just shouldn't expect to
> >> receive any responses right away.
> > I am not sure what you mean by fine. You will see hang notifications if
> > Xenstored is not started in time. Isn't why we decided to go with a 
> > different
> > way for dom0less?
>
> The main difference is that dom0 tells xenstored the connection parameters for
> itself, so dom0 _knows_ that the ring page is setup correctly when xenstored
> starts looking at it (it is dom0 which needs to do the ring page init).
>
> A dom0less domU doesn't have that negotiation with xenstored, as xenstored 
> just
> uses the pre-defined grant for looking at the ring page. For the domU there is
> no way to tell that xenstored has initialized the ring page (it is not the 
> domU
> to do the initialization, as the XS_INTRODUCE might be sent before the domU
> even starts running), other than the "connected" indicator in the page itself.

Any thoughts on my patch?  From your description, it sounds like maybe
it should be in the right direction, although it's currently missing
memory barriers.

 -George