WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/pv-on-hvm kexec+kdump: reset PV devices

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3/3] xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Tue, 9 Aug 2011 11:44:43 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Konrad <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 09 Aug 2011 02:46:07 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1312883133; l=1144; 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=Y4+ThucBQHOclQuXzvhtpMYPOxs=; b=ymJ1HtbCNJivNBwZfZtXhEimJDfNIOWCixzJpphyEcFvETTXZoLiJ33LPToFj1M5QFk YWFzO8dhfEzL6iRCMXUFxyKjBT/eIwyJIcXiRXvD8r+wV9so6+Yi5gOOrO6AcEH8GbZn5 KZv6jcbcQo25EyO2a2ERIvKONLGPlOq8nlk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1312881788.26263.50.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <20110804162053.723541930@xxxxxxxxx> <20110804162054.806626433@xxxxxxxxx> <1312881788.26263.50.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21.rev5535 (2011-07-01)
On Tue, Aug 09, Ian Campbell wrote:

> >  static int frontend_probe_and_watch(struct notifier_block *notifier,
> >                                unsigned long event,
> >                                void *data)
> >  {
> > +   /* reset devices in Connected or Closed state */
> > +   if (xen_hvm_domain())
>                                && reset_devices ??

No, reset_devices is passed as kernel cmdline option to a kdump boot.
But its not part of a kexec boot.

> How long should we wait for the backend to respond? Should we add a
> timeout and countdown similar to wait_for_devices?

Adding a timeout to catch a confused backend is a good idea. That would
give one at least a chance to poke around in a rescue shell.

> It's unfortunate that this code is effectively serialising on each
> device. It would be much preferable to kick off all the resets and then
> wait for them to occur. You could probably do this by incrementing a
> counter for each device you reset and decrementing it each time a watch
> triggers then wait for the counter to hit zero.

That feature needs more thought. Since xenbus_reset_state() is only
executed in the kexec/kdump case, the average use case is not slowed
down.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>