From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Konrad <konrad.wilk@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
Date: Tue, 9 Aug 2011 11:44:43 +0200 [thread overview]
Message-ID: <20110809094443.GD7283@aepfle.de> (raw)
In-Reply-To: <1312881788.26263.50.camel@zakaz.uk.xensource.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Konrad <konrad.wilk@oracle.com>
Subject: Re: [PATCH 3/3] xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
Date: Tue, 9 Aug 2011 11:44:43 +0200 [thread overview]
Message-ID: <20110809094443.GD7283@aepfle.de> (raw)
In-Reply-To: <1312881788.26263.50.camel@zakaz.uk.xensource.com>
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
next prev parent reply other threads:[~2011-08-09 9:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 16:20 [PATCH 0/3] [v4] kexec and kdump for Xen PVonHVM guests Olaf Hering
2011-08-04 16:20 ` [PATCH 1/3] xen/pv-on-hvm kexec: add xs_introduce to shutdown watches from old kernel Olaf Hering
2011-08-09 9:15 ` [Xen-devel] " Ian Campbell
2011-08-09 9:15 ` Ian Campbell
2011-08-09 9:28 ` [Xen-devel] " Olaf Hering
2011-08-04 16:20 ` [PATCH 2/3] xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports Olaf Hering
2011-08-09 9:17 ` [Xen-devel] " Ian Campbell
2011-08-09 9:29 ` Olaf Hering
2011-08-09 11:25 ` Ian Campbell
2011-08-09 15:28 ` Olaf Hering
2011-08-09 18:51 ` Konrad Rzeszutek Wilk
2011-08-04 16:20 ` [PATCH 3/3] xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel Olaf Hering
2011-08-09 9:23 ` [Xen-devel] " Ian Campbell
2011-08-09 9:44 ` Olaf Hering [this message]
2011-08-09 9:44 ` Olaf Hering
2011-08-09 11:26 ` [Xen-devel] " Ian Campbell
2011-08-09 19:02 ` [Xen-devel] [PATCH 0/3] [v4] kexec and kdump for Xen PVonHVM guests Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110809094443.GD7283@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.