Re: Paravirt KVM capabilities

Avi Kivity
2007-01-10T10:43:17Z

Ingo Molnar wrote:
> * 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.
>
>

If you have a CONFIG_PARAVIRT guest, I believe it will always be faster
to run it without hardware assisted virtualization:

- you cannot eliminate vmexits due to host interrupts
- a hypercall will (probably) keep being more expensive than a syscall;
it simply has a lot more work to do
- cr3 switches for CONFIG_PARAVIRT syscalls (which are necessary on
x86_64) will probably become very cheap with tagged tlbs

So, in my opinion, CONFIG_PARAVIRT on non-hvm will eventually win on
pure performance. Hardware assisted virtualization will be used where
you wish to run unmodified guests, and where ABI stability is critical.

I won't mind being proved wrong, though. And of course we should share
drivers and APIs between the two technologies.

--
error compiling committee.c: too many arguments to function