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

[Xen-devel] Propose "xen_init()" call first thing in Xen drivers


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 21 Sep 2005 14:51:08 -0700
  • Cc: Matt Chapman <matthewc@xxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 21 Sep 2005 21:49:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcW+9pLOkyKDvrA9Qg+azC7D1BUrcQ==
  • Thread-topic: Propose "xen_init()" call first thing in Xen drivers

Here's another patch needed for ia64 in various xen drivers
that should probably be discussed before the actual patch
code is attached/applied.

Per previous posts, Xenlinux/ia64 is transparently paravirtualized,
which means the same bits run on top of Xen as on top of raw
iron.

To accomplish this, we have to be very careful to avoid doing
Xen-like things when we are not running on Xen.  The Xen
drivers tend to do Xen-like things early and often.  To avoid
the Xen drivers doing nasty things when not running on Xen,
we have added a single line at the beginning of various
drivers/xen/xxx xxx_init() routines, namely:

        if (xen_init() < 0) return -ENODEV

Where xen_init does "if (running_on_xen()) return -1;"
(among other things... see below) and where
running_on_xen() does the obvious (archdep) test.
We have been maintaining these changes out-of-tree.

Note that the routine need not be provided on x86 as
the line can be easily ifdef'd away by adding

        #define xen_init()      (0)

in a file such as asm-x86/hypervisor.h.

But wait... on xenlinux/ia64, xen_init does something
else!  In xenlinux/x86 there was (not sure if it is still
there) some funky linker stuff to ensure that the drivers
are linked in the right order as bad things happened
if they weren't (due to the way init() works on Linux).
On xenlinux/ia64, xen_init() eliminates this problem with
a simple static one-shot variable in xen_init; regardless
of which routine calls xen_init first, xen_init does the
necessary initialization once.  No linker magic required.

So adding the xen_init test need not be ifdef'd away
for x86.

For xenlinux/ia64, we have the test added in a few
places, namely: xencons_init, gnttab_init, xenbus_probe_init.
It may also be needed elsewhere as we've been struggling
out-of-tree with keeping up with changes in driver/xen,
haven't tested on raw iron in awhile, don't have networking
working yet, etc.

So... how about we add the one line test to the init routines
of the various Xen drivers (including "core" drivers)?

Thanks,
Dan

P.S. The xen_init approach should be properly credited to
Matt Chapman.  I am just proposing it for the core tree.

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


 


Rackspace

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