Re: Paravirt KVM capabilities

Ingo Molnar
2007-01-10T09:47:50Z

* Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:

> > It's also something for the Linux community in general to decide: if
> > we want separate interfaces for paravirtualization and full
> > virtualization (lhype and kvm) or a merged interface. I can see
> > arguments in favor of both positions.
>
> Yeah, me too.
>
> Ignoring technical questions for a moment, the main issue is
> that lhype doesn't have an ABI; you have to run the same(ish) kernel
> as guest and host. This is by design: I wanted it to be a platform
> for experimentation and hacking, because I think we're still at that
> stage with x86 Linux virtualization.

i really really think KVM and lhype should merge, creating KVM/HVM
(Hardware Virtual Machine) and KVM/LL (Linux on Linux). But that's
really your business to decide, not mine :-) I guess it's not a pure
technical decision :-/

( later on KVM/LL could be extended to also run unmodified guests
similar to how kqemu does it: by running guest user-space on ring 3
and letting Qemu do all of ring0 emulation. That is already leagues
faster than default Qemu, and it would also nicely test lhype's
cr3/pagetable management infrastructure. It can also run most 32-bit
OSs out there - largely extending the userbase even on legacy
hardware. )

regarding ABI: agreed that it's experimental right now and should stay
so for some time, but i dont see a reason why the hypercall API that
i've posted in the past few days couldnt be evolved in the way Linux
syscalls evolve, by only adding to them. That doesnt really impact the
flexibility of the virtualization subsystem. We could also possibly
phase out older hypercalls, because the number of "applications" relying
on it will be very low.

Ingo