Re: Paravirt KVM capabilities

Avi Kivity
2007-01-10T17:23:17Z

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Ingo Molnar wrote:
>>
>>> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>>
>>>
>>>
>>>> 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
>>>>
>>>>
>>> but irq overhead is nothing in importance compared to basic syscall
>>> overhead. KVM/HVM already runs guest kernel syscalls at native speed.
>>> KVM/LL (or Xen) has to switch cr3s to enter guest kernel context, and
>>> has to switch it back to get back to guest user context. It might be
>>> pretty fast with tagged TLBs, but not zero-cost.
>>>
>>>
>>
>> For i386 Xen does not switch cr3 IIRC. Perhaps even not for x86_64 if
>> it can use the segment limits which AMD re-added (I think it does?)
>>
>
> Xen setups the IDT to deliver directly to ring 1 for syscalls as you
> suggested.
>
> At the moment, Xen doesn't make use of the segment limits on AMD on
> 64bit. Currently, the guest kernel runs in ring 3 and I presume there
> are a good deal of assumptions about that.
>
> Xen does, however, use global pages for the kernel (and it's) memory
> so that should help a bit.

That means it needs to flush the Xen tlb entries on domain switch. I
guess that's a good tradeoff since guest context switches are more
common than domain switches.

>
> One thing to consider though is how things like hardware nested paging
> and CR3 caching come into play. On a context switch, a Xen style
> paravirt has to use hypercalls to change CR3 (since it's privileged)
> whereas on VT, there's at least the chance of hitting the cache before
> taking a VMEXIT.
>
> Also, nested paging should considerably change the performance
> characteristics of a FV guest. While TLB lookups will end up being
> more expensive (since more memory accesses are required), the overall
> cost of page fault handling will go down significantly. Recall, even
> in direct paged mode, Xen has to take page faults in the hypervisor
> first. With nested paging, presumably page faults can be delivered
> directly to the guest[1].

I agree that nested page tables changes things dramatically wrt.
paging. My comments apply only to non-nested paging.

>
> [1] This assumes that the implementation will allow for physical
> memory holes which will result in VMEXITs (for MMIO emulation).

The assumption is correct according to my reading of the docs. NPT can
deliver a #PF or a #VMEXIT(NPF), with the expected semantics.

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