[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] Handle failure to register the xen store event channel instead of



# HG changeset patch
# User Ian.Campbell@xxxxxxxxxxxxx
# Node ID d0d3fef37685be264a7f52201f8ef44c030daad3
# Parent  4ad317429111d43cc99810af25b3faf6ffed4209
Handle failure to register the xen store event channel instead of
just not initialising xenbus/store when the supervisor_mode_kernel
feature flag is enabled.

When initialising grant tables only -ENOSYS is a valid reason
to fail so BUG_ON anything else like we did prior to changeset
9498.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxxxxx>

diff -r 4ad317429111 -r d0d3fef37685 
linux-2.6-xen-sparse/drivers/xen/core/gnttab.c
--- a/linux-2.6-xen-sparse/drivers/xen/core/gnttab.c    Sun Apr  2 15:16:53 2006
+++ b/linux-2.6-xen-sparse/drivers/xen/core/gnttab.c    Mon Apr  3 13:34:20 2006
@@ -395,10 +395,10 @@
        setup.frame_list = frames;
 
        rc = HYPERVISOR_grant_table_op(GNTTABOP_setup_table, &setup, 1);
-       if (rc < 0)
-               return rc;
-
-       BUG_ON(setup.status);
+       if (rc == -ENOSYS)
+               return -ENOSYS;
+
+       BUG_ON(rc || setup.status);
 
 #ifndef __ia64__
        if (shared == NULL) {
diff -r 4ad317429111 -r d0d3fef37685 
linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c
--- a/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c    Sun Apr  2 
15:16:53 2006
+++ b/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c    Mon Apr  3 
13:34:20 2006
@@ -984,6 +984,7 @@
 static int __init xenbus_probe_init(void)
 {
        int err = 0, dom0;
+       unsigned long page = 0;
 
        DPRINTK("");
 
@@ -992,19 +993,9 @@
                return -ENODEV;
        }
 
-       /* Register ourselves with the kernel bus & device subsystems */
+       /* Register ourselves with the kernel bus subsystem */
        bus_register(&xenbus_frontend.bus);
        bus_register(&xenbus_backend.bus);
-       device_register(&xenbus_frontend.dev);
-       device_register(&xenbus_backend.dev);
-
-       /*
-         * The supervisor_mode_kernel feature only allows a single
-         * domain so there is no need to initialise event channels
-         * etc.
-         */
-       if (xen_feature(XENFEAT_supervisor_mode_kernel))
-               return -ENODEV;
 
        /*
         * Domain0 doesn't have a store_evtchn or store_mfn yet.
@@ -1012,11 +1003,7 @@
        dom0 = (xen_start_info->store_evtchn == 0);
 
        if (dom0) {
-
-               unsigned long page;
                evtchn_op_t op = { 0 };
-               int ret;
-
 
                /* Allocate page. */
                page = get_zeroed_page(GFP_KERNEL);
@@ -1032,8 +1019,10 @@
                op.u.alloc_unbound.dom        = DOMID_SELF;
                op.u.alloc_unbound.remote_dom = 0;
 
-               ret = HYPERVISOR_event_channel_op(&op);
-               BUG_ON(ret);
+               err = HYPERVISOR_event_channel_op(&op);
+               if (err == -ENOSYS)
+                       goto err;
+               BUG_ON(err);
                xen_start_info->store_evtchn = op.u.alloc_unbound.port;
 
                /* And finally publish the above info in /proc/xen */
@@ -1056,13 +1045,29 @@
        if (err) {
                printk(KERN_WARNING
                       "XENBUS: Error initializing xenstore comms: %i\n", err);
-               return err;
-       }
+               goto err;
+       }
+
+       /* Register ourselves with the kernel device subsystem */
+       device_register(&xenbus_frontend.dev);
+       device_register(&xenbus_backend.dev);
 
        if (!dom0)
                xenbus_probe(NULL);
 
        return 0;
+
+ err:
+       if (page)
+               free_page(page);
+
+       /*
+         * Do not unregister the xenbus front/backend buses here. The
+         * buses must exist because front/backend drivers will use
+         * them when they are registered.
+         */
+
+       return err;
 }
 
 postcore_initcall(xenbus_probe_init);

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.