>[*]Having a single kernel image that works native and on a hypervisor
is
>quite convenient from a user POV. We've looked into addressing this
>problem in a different way, by building multiple kernels and then using
>a tool that does a function-by-function 'union' operation, merging the
>duplicates and creating a re-write table that can be used to patch the
>kernel from native to Xen. This approach has no run time overhead, and
>is entirely 'mechanical' rather than having to having to do it as
source
>level that can be both tricky and messy.
If you are going to hide all the Xen logic behind
static inline wibble_with_foo (int bar, int blat) {
#ifdef CONFIG_XEN
do A
#else
do B
#endif
}
anyway, why is it so tricky and messy to instead do
static inline __wibble_with_foo (int bar, int blat) {
do B
}
static inline wibble_with_foo (int bar, int blat) {
#ifdef CONFIG_XEN
if (running_on_xen)
do A
else
#else
__wibble_with_foo(bar,blat);
#endif
}
This is essentially what Xen/ia64 does, it works today,
and the performance impact is negligible ("running_on_xen"
is a set-once-at-boot global variable; if it's read
frequently, it's fast because its always in cache,
if it's not read frequently, by definition its not a
performance issue). Granted there will be more of
these if-xen functions on x86 than on ia64 because
of the memory management paravirtualization, but the
model is still the same.
Structured properly, the Xen-specific code can even
be hidden away in Xen-specific header files (as it is
in Xen/ia64).
I can guarantee that Vmware's solution will be
transparently paravirtualized, *won't* require some funky
complicated linktime tool which massages the kernel binary
in unusual (and possibly error prone) ways, and, as such,
will look even more seductive to the linux developers.
Oh, and "function-by-function 'union' operation" and
"creating a re-write table that can be used to patch"
sound very close to the Vmware solution to me. I suspect
it will be even harder to sell Xen over VMPI to the
Linux developers if they have to deal with an indirection
table anyway, even if it is handled statically instead
of dynamically.
Just my two cents... (OK, maybe three :-)
Dan "transparent paravirtualization R us" Magenheimer
P.S. Last, the "running_on_xen" solution has at least the
hint that it might be devirtualizable... allowing a virtual
machine to be dynamically v-to-p'ed and vice-versa.
(See Dave Lowell's paper in ASPLOS last year.)
_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge
|
Home