From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: pv-on-hvm kexec, howto reregister timer interrupt Date: Sat, 23 Jul 2011 10:52:29 +0200 Message-ID: <20110723085229.GA14838@aepfle.de> References: <1311408105.4027.80.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1311408105.4027.80.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Sat, Jul 23, Ian Campbell wrote: > On Sat, 2011-07-23 at 07:57 +0100, Keir Fraser wrote: > > On 22/07/2011 19:49, "Olaf Hering" wrote: > > > > > What is the best way to reregister the timer interrupt in the kexec > > > kernel in a pv-on-hvm guest? Right now the crash shown below happens > > > because EVTCHNOP_bind_virq returns -EEXIST. Can the timer on the cpus be > > > unregistered during shutdown? xen_teardown_timer() does not allow that > > > for cpu #0. I added some silly loop which tries to match vcpu/cpu in > > > bind_virq_to_irq() using EVTCHNOP_status to find the currently used port > > > number. This helps and booting proceeds, but I feel that cant be the > > > right approach. > > > > Sounbds like it's simply some Linux-guest issue here to be untangled. All > > Xen requires you to do is EVTCHNOP_close the old virq-evtchn binding. > > That might be tricky to do in the target kernel, which may not know what > needs closing. There's EVTCHNOP_reset which looks like it would be a > sensible thing to call early on in the target but seems like it would > close to much -- e.g. the xenstore evtchn? After some more poking around in the reboot code path I have figured it out, a syscore_ops has to be registerd to shutdown the irqs. I will post some patches for review. Olaf