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 13:56:21 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 28 Jul 2011 05:57:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110728110219.GA22307@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> <1311850379.24408.119.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110728110219.GA22307@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-07-28 at 07:02 -0400, Olaf Hering wrote:
> On Thu, Jul 28, Ian Campbell wrote:
> > Getting into the kdump kernel is a kexec like operation though and
> > shares many of the code paths, doesn't it?
> The big difference is that kdump is entered in an unreliable state,
> while kexec is a controlled reboot.

Sure, but by handling the former you also solve the later, while the
opposite is not true.

> > > > 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.
> I wonder why xenstore knows that sysrq and shutdown nodes are busy,
> while the device, backend and state files can be watched twice.

Do the precise path's watched differ subtly?

Oh, I see, xenstored only calls a watch a duplicate if both the path
_and_ the token match. In the case of backend paths the token is a
reference to the dynamically allocated per-device data structure. In the
sysrq and shutdown case the token is a static global variable -- I
suppose you are kexec'ing an identical kernel? I expect that if you
kexec'd a subtly different kernel where these datastructures ended up at
a different address you wouldn't get the EEXIST.


Xen-devel mailing list