From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel Date: Mon, 15 Aug 2011 14:59:58 +0200 Message-ID: <20110815125958.GA4795@aepfle.de> References: <4b483f4fa715566847b5.1313397256@probook.site> <20110815092530.GA3001@aepfle.de> <20110815125306.GA11127@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <20110815125306.GA11127@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Mon, Aug 15, Konrad Rzeszutek Wilk wrote: > On Mon, Aug 15, 2011 at 11:25:30AM +0200, Olaf Hering wrote: > > Add new xs_reset_watches function to shutdown watches from old kernel after > > kexec boot. The old kernel does not unregister all watches in the > > shutdown path. They are still active, the double registration can not > > be detected by the new kernel. When the watches fire, unexpected events > > will arrive and the xenwatch thread will crash (jumps to NULL). An > > orderly reboot of a hvm guest will destroy the entire guest with all its > > resources (including the watches) before it is rebuilt from scratch, so > > the missing unregister is not an issue in that case. > > So this patch replaces the big patch series you sent some while ago? > [I've one of your patches in my tree, but I wasn't sure about the other > ones] No, there are 3 other patches required: xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when stale watch events arrive I will send them once we settled on a way to reset the watches. Which one did you already apply? > If the xenstore does not have the patch for this, what is the > error code? Is it ENOSYS? If we get that can we not print this message? > Or perhaps print: > "Yikes! We can't reset the watches. Potential crash immienient" > or something similar. Now that you mention it, the return code should be checked and ENOSYS should be filtered to not print the warning on a host without the updated xenstored. I will update that part of the patch. Olaf