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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 28.07.11 at 07:25, Olaf Hering <olaf@xxxxxxxxx> 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.

Oh, I implied it would be kdump.

But then again xenstore state shouldn't matter wrt the purpose of
the secondary kernel.

> The kdump kernel runs in its own memory range, so memory corruption does
> not appear to happen (with the sles11sp1 kernel + my kdump patch).

It's also not clear to me what corruption there is - this would seem to
imply that there should be information on certain addresses that were
used in the old kernel to get passed to the new kernel, or get used to
access guest memory from outside the guest. All of which sounds
wrong.

Jan

>> 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? 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.
> 
> Olaf




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