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: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 28 Jul 2011 11:52:59 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 28 Jul 2011 03:53:48 -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>
Organization: Citrix Systems, Inc.
References: <4E30A9BC0200007800073B1F@xxxxxxxxxxxxxxxxxxxx> <20110728052500.GA13940@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


Xen-devel mailing list