Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred

[Jürgen Groß <jgross@xxxxxxxx>]

On 29.04.20 13:04, Igor Druzhinin wrote:
> On 29/04/2020 11:49, Jürgen Groß wrote:
> > On 29.04.20 12:39, Igor Druzhinin wrote:
> > > On 29/04/2020 10:22, Julien Grall wrote:
> > > > Hi Juergen,
> > > >
> > > > On 29/04/2020 06:51, Jürgen Groß wrote:
> > > > > Recreating the event channel would be fine, but I don't see why it
> > > > > would ever be needed. And XS_INTRODUCE is called only at domain creation
> > > > > time today, so there is obviously no need for repeating this call.
> > > > >
> > > > > Maybe the idea was to do this after sending a XS_RESUME command, which
> > > > > isn't used anywhere in Xen and is another part of Xenstore which doesn't
> > > > > make any sense today.
> > > > Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE 
> > > > evtchn rebind function from cxenstored" added the exact same behavior in the OCaml 
> > > > XenStored last year.
> > > >
> > > > This was introduced 12 years after C XenStored, so surely someone think this is 
> > > > useful. We should check why this was introduced in OCaml XenStored (I have CCed 
> > > > the author of the patch).
> > > >
> > > > If we still think this is not useful, then you should add an explanation in the 
> > > > commit message why the two implementations diverge and possibly update the spec.
> > > Thanks for CC, Julien.
> > >
> > > We indeed already use this functionality in our toolstack for guest kdump
> > > functions. It's not possible in XAPI to adopt libxl model where almost 
> > > everything
> > > is restarted for a domain entering kdump, so we have to use this message to
> > > rebind xenstore evtchn after soft reset without shutting down backends and
> > > recreating the whole subtree (frontends reconnect fine after that).
> > >
> > > We obviously only require it for now to be present in oxenstored only.
> > > Please don't remove this functionality if possible.
> > If I read handling in libxl correctly, in the soft reset case XS_RELEASE
> > is issued before doing another XS_INTRODUCE. XS_RELEASE will result in
> > xenstored throwing away its related struct domain, so XS_INTRODUCE will
> > be possible again.
>  From what I remember it was not possible to keep xenstored data for a domain
> and at the same time perform release-introduce cycle (at least in oxenstored).
> It also involved firing @releaseDomain which caused havoc in other part of
> the toolstack.
Wei, Ian, can you please tell me where I'm wrong?

A soft reset should restart the domain in a clean state. AFAIK libxl is
handling that by doing kind of in-place save-restore, including calling
xs_release_domain() and later xs_introduce_domain(). This should result
in xenstored throwing away all state it has regarding the domain and
then restarting with a new (internal) domain instance.

Is XAPI doing soft reset differently? Why should there be a need for
keeping xenstored data across a soft reset?


Juergen