Re: Paravirt KVM capabilities

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>]

On Thu, 2007-01-11 at 01:49 +0100, Ingo Molnar wrote:
> * Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
> 
> > > > - 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
> > 
> > Err no, this isn't true.  See Documentation/lhype.txt or various blog 
> > entries on the subject 8) Both Xen and lhype get native syscall speeds 
> > (within measurement error).
> 
> i was talking about 64-bit. (we dont really design for 32-bit anymore.) 

Oh, ok, because there doesn't seem much point to avoiding using HVM if
you're assuming 64 bit, except as an optimization.  Full paravirt is
more useful for 32-bit, hence lhype started there...

> I know that lhype uses Xen's ring 1 trick, but that's a 32-bit-only 
> thing. Also, can SYSENTER trap from guest userspace ring 3 into guest 
> kernelspace ring 1 on lhype?

As I understand it, sysenter has to go to ring 0, and the reflection
cost is way greater than the saving.

Rusty.



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