This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Olaf Hering" <olaf@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2/6] xen/hvm kexec: unregister shutdown+sysrq watches during reboot
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 28 Jul 2011 17:09:41 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 28 Jul 2011 09:10:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110728052500.GA13940@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E30A9BC0200007800073B1F@xxxxxxxxxxxxxxxxxxxx> <20110728052500.GA13940@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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


>> 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