Re: Paravirt KVM capabilities

Ingo Molnar
2007-01-10T10:18:39Z

* Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Ingo Molnar wrote:
> > i really really think KVM and lhype should merge, creating KVM/HVM
> > (Hardware Virtual Machine) and KVM/LL (Linux on Linux).
>
> This is only sufficient if either KVM with paravirt Linux kernels has
> no performance penalty or lhype becomes able to execute paravirt Linux
> kernels.

yes, both would be the goal i think. Single kernel image can run as a
KVM host, as a KVM/HVM guest [if CPU support] or as a KVM/LL guest [if
no CPU support]. There's no hypercall overhead on native kernels, we
have binary-patching infrastructure in place to turn them into NOPs.
(which makes it quite close to zero-cost)

right now the KVM paravirtualization work we are doing is gradually
transitioning KVM/HVM towards KVM/LL in essence, by eliminating all VM
exit reasons from KVM/HVM and turning them into hypercalls. Once that
has been achieved, KVM/LL could be implemented by an extra ll.c module
in drivers/kvm/, which does the cr3 tricks and pagetable maintainance
and CPU state save/restore, fault/trap/irq passback (and not much else).

So i see very nice short and long term synergy between native Linux,
KVM/HVM guests and KVM/LL guests. What is an hypercall-accelerated
driver under KVM/HVM is a paravirtual driver on KVM/LL. What is a
hypercall-based speedup for KVM/HVM is a paravirtual facility for
KVM/LL. One and the same thing serves both purposes.

> I can certainly attest that there is a lot of demand for running Linux
> domains with kernels other than the one running on the hardware. This
> is Xen's bread and butter and from the albeit old numbers I've seen so
> far KVM has problems competing.

yes. Running /any/ OS with maximum possible performance is the goal, and
i'd like the hypercall API to become an ABI in essence, with as much
backwards compatibility for older kernels as possible.

Ingo