[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 01:25 -0400, Olaf Hering wrote: > On Thu, Jul 28, Jan Beulich wrote: > > > >>> On 26.07.11 at 13:52, Olaf Hering <olaf@xxxxxxxxx> wrote: > > > Unregister the shutdown and sysrq watch during kexec. The watches can > > > not be re-registered in the kexec kernel because they are still seen as > > > busy by xenstore. > > > > This and subsequent patches don't look right to me from a conceptual > > pov: If the kexec attempt is due to a crash, the dying kernel should be > > doing as little as possible, and the new kernel should really do the > > cleanup. The more logic gets added to the shutdown path of the old > > kernel, the more likely it'll become that the kexec attempt will fail. > > kexec is about reboot, kdump is about crash handling. Both use different > code paths. > The kexec code path is like a reboot without going through the firmware. > The kdump kernel runs in its own memory range, so memory corruption does > not appear to happen (with the sles11sp1 kernel + my kdump patch). Getting into the kdump kernel is a kexec like operation though and shares many of the code paths, doesn't it? > > 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. > And what about the event/irq handling? There is currently no way > to check what virq is bound to what port, other than looping through all > possible ports and see if one matches the requested virq. There is EVTCHNOP_reset but I'm not sure if it does too much. For example I'm not sure how the guest could recover event channels which are setup by the domain builder -- such as the xenstore event channel. IIRC EVTCHNOP_reset was added to aid with kexec though -- so I must be missing something. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |