[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/6] xen/hvm kexec: unregister shutdown+sysrq watches during reboot
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |