All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kieran Mansley <kmansley@solarflare.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "andy@cs.ubc.ca" <andy@cs.ubc.ca>,
	Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel@lists.xensource.com
Subject: Re: [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume
Date: Tue, 07 Apr 2009 10:26:58 +0100	[thread overview]
Message-ID: <1239096418.4273.13.camel@moonstone.uk.level5networks.com> (raw)
In-Reply-To: <1238663621.4271.13.camel@moonstone.uk.level5networks.com>

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Thu, 2009-04-02 at 10:13 +0100, Kieran Mansley wrote:
> OK, I'll try and produce a patch based on the assumptions that (i)
> watches won't fire between suspend and either resume or suspend-cancel;
> (ii) any that would have fired are triggered after a suspend-cancel; and
> (iii) the watch must be refreshed on a resume (with no guarantees about
> lost watches).

OK, here's the patch.

Signed-off-by: Kieran Mansley <kmansley@solarflare.com>

Keir: I'll leave it up to you as to whether this is a bug fix (and so
should be included in 3.4) or just queued for unstable after 3.4 is
released.  Either is fine with us.

Thanks

Kieran 

[-- Attachment #2: suspend_watch --]
[-- Type: text/plain, Size: 2698 bytes --]

Avoid removing watch across suspend/suspend_cancel cycle

diff -r b358ebf1c416 drivers/xen/netfront/accel.c
--- a/drivers/xen/netfront/accel.c
+++ b/drivers/xen/netfront/accel.c
@@ -50,6 +50,8 @@ static int netfront_load_accelerator(str
 static int netfront_load_accelerator(struct netfront_info *np, 
 				     struct xenbus_device *dev, 
 				     const char *frontend);
+
+static void netfront_accelerator_remove_watch(struct netfront_info *np);
 
 /*
  * List of all netfront accelerator plugin modules available.  Each
@@ -164,8 +166,11 @@ void netfront_accelerator_add_watch(stru
 {
 	int err;
 	
-	/* Check we're not trying to overwrite an existing watch */
-	BUG_ON(np->accel_vif_state.accel_watch.node != NULL);
+	/* 
+	 * If old watch exists, e.g. from before suspend/resume,
+	 * remove it now 
+	 */
+	netfront_accelerator_remove_watch(np);
 
 	/* Get a watch on the accelerator plugin */
 	err = xenbus_watch_path2(np->xbdev, np->xbdev->otherend, 
@@ -180,6 +185,19 @@ void netfront_accelerator_add_watch(stru
 }
 
 
+static void 
+netfront_accelerator_purge_watch(struct netfront_accel_vif_state *vif_state)
+{
+	flush_workqueue(accel_watch_workqueue);
+
+	/* Clean up any state left from watch */
+	if (vif_state->accel_frontend != NULL) {
+		kfree(vif_state->accel_frontend);
+		vif_state->accel_frontend = NULL;
+	}
+}
+
+
 static
 void netfront_accelerator_remove_watch(struct netfront_info *np)
 {
@@ -191,13 +209,7 @@ void netfront_accelerator_remove_watch(s
 		kfree(vif_state->accel_watch.node);
 		vif_state->accel_watch.node = NULL;
 
-		flush_workqueue(accel_watch_workqueue);
-
-		/* Clean up any state left from watch */
-		if (vif_state->accel_frontend != NULL) {
-			kfree(vif_state->accel_frontend);
-			vif_state->accel_frontend = NULL;
-		}
+		netfront_accelerator_purge_watch(vif_state);
 	}	
 }
 
@@ -670,8 +682,6 @@ int netfront_accelerator_suspend(struct 
 {
 	int rc = 0;
 	
-	netfront_accelerator_remove_watch(np);
-
 	mutex_lock(&accelerator_mutex);
 
  	/* Check that we've got a device that was accelerated */
@@ -692,13 +702,16 @@ int netfront_accelerator_suspend_cancel(
 int netfront_accelerator_suspend_cancel(struct netfront_info *np,
  					struct xenbus_device *dev)
 {
+	netfront_accelerator_purge_watch(&np->accel_vif_state);
+
 	/* 
-	 * Setting the watch will cause it to fire and probe the
-	 * accelerator, so no need to call accelerator_probe_new_vif()
-	 * directly here
+	 * Gratuitously fire the watch handler to reinstate the
+	 * configured accelerator
 	 */
 	if (dev->state == XenbusStateConnected)
-		netfront_accelerator_add_watch(np);
+		queue_work(accel_watch_workqueue, 
+			   &np->accel_vif_state.accel_work);
+
 	return 0;
 }
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2009-04-07  9:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 16:53 [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume Brendan Cully
2009-03-31 17:24 ` Brendan Cully
2009-03-31 17:35   ` Keir Fraser
2009-03-31 20:04     ` Brendan Cully
2009-04-01 10:26       ` Kieran Mansley
2009-04-01 10:31         ` Keir Fraser
2009-04-01 11:00           ` Kieran Mansley
2009-04-01 18:39             ` Brendan Cully
2009-04-02  8:13               ` Kieran Mansley
2009-04-02  8:27                 ` Keir Fraser
2009-04-02  9:13                   ` Kieran Mansley
2009-04-07  9:26                     ` Kieran Mansley [this message]
2009-04-01 20:36         ` Ian Campbell

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=1239096418.4273.13.camel@moonstone.uk.level5networks.com \
    --to=kmansley@solarflare.com \
    --cc=andy@cs.ubc.ca \
    --cc=brendan@cs.ubc.ca \
    --cc=keir.fraser@eu.citrix.com \
    --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.