[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-merge] FW: vmware's virtual machine interface
>[*]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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |