On Thu, 2006-05-18 at 15:24 +0200, Andi Kleen wrote:
> > I don't think it's beautiful, no, but any abstraction layer is going to
> > have an impact, and you should probably compare it with the
> > alternatives.
>
> Alternative is separate binary for Xen kernel and VMI/native (which doesn't need
> any ops, just easily predictable and human readable jumps and can be also
> run natively without too much impact).
Hi Andi!
Indeed, and it's a trade-off. VMI *is* an ops table, just with an asm
interface, and not changeable by Linux. ie. a very poor one, from the
Linux point of view. OTOH, a standard ops table is the simplest
possible implementation we can have, and every kernel coder understands
them.
As to performance, I believe we'll need to patch the call sites for
critical insns anyway. (I'll code up something today to demonstrate
this, pref. with benchmarks). My thesis is that it won't matter that
the call through the ops table is kinda slow, because we'll be patching
over that anyway where we care. If I'm wrong, we should be able to tell
soon.
> In fact I bet the Xen kernel could
> run natively too without too much impact by just using a simple stub hypervisor,
> but for that the VMI approach seems better.
Indeed, it's called microxen. Do we really want to go there? I like
having the kernel all within the kernel sources.
> Frankly I don't see us supporting a zillion different more hypervisor
> interfaces neither and the both approaches ("high level" like in Xen
> and "low level" like in VMI) should cover most of the use space already
> anyways.
I hope there is, because I think there's room for improvement. But
even if we don't have any more hypervisors in mainline, we're going to
have multiple versions of both of these quite quickly.
Hope that clarifies,
Rusty.
--
ccontrol: http://ccontrol.ozlabs.org
