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: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2/6] xen/hvm kexec: unregister shutdown+sysrq watches during reboot
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Thu, 28 Jul 2011 07:25:00 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 27 Jul 2011 22:26:46 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1311830763; l=1426; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=us42Ad+sGB5JZZ6Me1ePl+uM9q8=; b=PBBmMTsP7cks7Uc34vLHfCebW9fJSIkXrsA5oXmqR0754qpVR/5FyDXEBUSfxyh+5ip cQDhn3e6AOK0FHpww+Z1ehHWw1Og/YjsWfGDWN7MWQK5gi0wu5s+sTtOK8f604h+cCo1W b33VSuniqbZDYzivgSYndXo6qgR5SioOy+M=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E30A9BC0200007800073B1F@xxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21.rev5535 (2011-07-01)
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).

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


Xen-devel mailing list