Re: [Xen-devel] [PATCH 2/6] xen/hvm kexec: unregister shutdown+sysrq watches during reboot

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2011-07-28 at 07:02 -0400, Olaf Hering wrote:
> On Thu, Jul 28, Ian Campbell wrote:
> 
> > Getting into the kdump kernel is a kexec like operation though and
> > shares many of the code paths, doesn't it?
> 
> The big difference is that kdump is entered in an unreliable state,
> while kexec is a controlled reboot.

Sure, but by handling the former you also solve the later, while the
opposite is not true.

> > > > If this requires changes outside the kernel (e.g. state reset helpers
> > > > in hypervisor or tools) - so be it.
> > > 
> > > Are you suggesting that there have to be ways for a domU to query the
> > > state of its registered watches and shut them all down during very early
> > > boot?
> > 
> > Perhaps the xenstore protocol could be enhanced with a mechanism to
> > clear all existing watches? A kernel could call that at start of day.
> 
> I wonder why xenstore knows that sysrq and shutdown nodes are busy,
> while the device, backend and state files can be watched twice.

Do the precise path's watched differ subtly?

Oh, I see, xenstored only calls a watch a duplicate if both the path
_and_ the token match. In the case of backend paths the token is a
reference to the dynamically allocated per-device data structure. In the
sysrq and shutdown case the token is a static global variable -- I
suppose you are kexec'ing an identical kernel? I expect that if you
kexec'd a subtly different kernel where these datastructures ended up at
a different address you wouldn't get the EEXIST.

Ian.



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