Re: Paravirt KVM capabilities

[Anthony Liguori <aliguori-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

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.

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].

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

Regards,

Anthony Liguori

> I think for i386 Xen does not go through the hypervisor at all: it hacks
> int 0x80 to trap directly to ring 1.  So there's still the overhead of
> using int rather than sysenter, but not much more.  I don't know how the
> (many syscalls) x (smaller overhead) vs (fewer interrupts) x (greater
> overhead) stack up.
>
>
> --
> error compiling committee.c: too many arguments to function
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV