Re: Paravirt KVM capabilities

Rusty Russell
2007-01-11T02:39:48Z

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.