Re: [Xen-devel] [PATCH] xenstored: allow guests to reintroduce themselves

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-08-09 at 10:17 +0100, Olaf Hering wrote:
> 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@xxxxxxxxx>
> > > # 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.

Right, part of the check for an existing watch is to check the "token"
and since the token is usually a pointer to kernel memory it will
probably be different for the kdump kernel. Although not necessarily if
you are unlucky or your kdump kernel is the same as the crashing kernel
but in different physical address (since it is the virtual addresses in
the pointer which matter).

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

That might be a good place to check, although I think we are still
missing the mechanism to expose such properties...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel