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


[Xen-devel] RE: bug in evtchn_cpu_notify (was domains not shutting down

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: bug in evtchn_cpu_notify (was domains not shutting down properly-theproblemisbackagain)
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 3 Jan 2009 18:04:25 +1100
Delivery-date: Fri, 02 Jan 2009 23:04:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D0155017C@trantor>
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: <AEC6C66638C05B468B556EA548C1A77D01550177@trantor><C583E3EB.20ADF%keir.fraser@xxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0155017A@trantor> <AEC6C66638C05B468B556EA548C1A77D0155017B@trantor> <AEC6C66638C05B468B556EA548C1A77D0155017C@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-topic: bug in evtchn_cpu_notify (was domains not shutting down properly-theproblemisbackagain)
> I think I've figured out what is going on... the 'per user data' in
> drivers/xen/evtchn/evtchn.c is per connection to the event channel
> so the same 'per user data' may be assigned to multiple ports
> Initially all the event channels opened by xenstored (eg 17 and 18)
> '1' in the vcpu of their user data, indicating that ports on that
> connection are bound to vcpu 1.
> In evtchn_cpu_notify(CPU_DOWN_PREPARE) (when xend starts, reducing the
> number of cpu's in dom0 to 1), every port is looped through. Port 17
> found to be bound to vcpu 1 (via the per user data) which is about to
> away, so the port is rebound to vcpu 0 and the user data is updated to
> reflect the new vcpu (I only have 2 cpu's, so it is set to 0 as 1 is
> away). Port 18 is checked but because the per-user data has been
> to vcpu=0 so nothing is done and the port stays bound to vcpu 1.
> I'll try and come up with a solution when I get back to my computer in
> few hours if nobody beats me to it... is there another way to check
> vcpu a port is bound to than checking the per-user value of bind_vcpu?

This patch fixes the problem for me... it doesn't require any new data
structures and evtchn_cpu_notify is hardly a performance critical code
path so I think we can wear the extra looping...

diff -r 618fc299e2f1 drivers/xen/evtchn/evtchn.c
--- a/drivers/xen/evtchn/evtchn.c  Thu Dec 18 11:51:36 2008 +0000
+++ b/drivers/xen/evtchn/evtchn.c  Sat Jan 03 18:01:04 2009 +1100
@@ -497,7 +497,7 @@
   int hotcpu = (unsigned long)hcpu;
   cpumask_t map = cpu_online_map;
-  int port, newcpu;
+  int port, port2, newcpu;
   struct per_user_data *u;

   switch (action) {
@@ -508,7 +508,9 @@
       if ((u = port_user[port]) != NULL &&
           u->bind_cpu == hotcpu &&
           (newcpu = next_bind_cpu(map)) < NR_CPUS) {
-        rebind_evtchn_to_cpu(port, newcpu);
+        for (port2 = port; port2 < NR_EVENT_CHANNELS; port2++)
+          if (port_user[port2] == u)
+            rebind_evtchn_to_cpu(port2, newcpu);
         u->bind_cpu = newcpu;

Xen-devel mailing list