Re: [PATCH] xenstored: allow guests to reintroduce themselves

[Olaf Hering <olaf@aepfle.de>]

On Tue, Aug 09, Ian Campbell wrote:

> On Mon, 2011-08-01 at 13:38 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1312202176 -7200
> > # Node ID edb96c34f4a638e8ba97933b6bd76ff72836353e
> > # Parent  0f36c2eec2e1576b4db6538b5f22d625587c1a15
> > xenstored: allow guests to reintroduce themselves
> > 
> > During kexec all old watches have to be removed, otherwise the new
> > kernel will receive unexpected events. Allow a guest to introduce itself
> > and cleanup all of its watches.
> 
> Just out of interest what happens if a guest tries to use this operation
> on an older xenstored which does not support it? I guess it gets an
> enosys type response?

It does, conn->id is not zero and the modified function returns early.

> Is there any way we can arrange to probe for this feature in order to
> fail to register for kexec/kdump early on rather than failing at the
> point where we attempt to actually kexec (where failure might come as
> rather an unpleasant surprise). I don't think we've historically had a
> mechanism for negotiating features with xenstored itself so I'm not sure
> what would be best here. Perhaps xenstored itself should
> expose /xenstored/feature-FOO nodes?

This patch is only for kexec boots, with kdump the crash in the kdump
kernel may happen as well but so far I have not seen it. Maybe because
the kdump kernel runs in its own memory range.

If you prefer, kexec can be modified to check for certain xenstored
properties.

Olaf