|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 2/6] xen/hvm kexec: unregister shutdown+sysrq wat
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
|
|
|
|
|