[Lguest] lguest: unhandled trap 13

[Rusty Russell]

On Thu, 11 Feb 2010 04:22:33 pm Avi Kivity wrote:
> On 02/11/2010 03:30 AM, Rusty Russell wrote:
> > On Thu, 11 Feb 2010 07:30:06 am Avi Kivity wrote:
> >    
> >> On 02/10/2010 04:33 AM, Rusty Russell wrote:
> >>      
> >>> Note that lguest doesn't run under kvm (I should really file a kvm bug)
> >>>        
> >> Yes please.
> >>
> >> How does it fail?
> >>      
> > I was hoping to get cycles to look at it myself.
> >
> > Host (ie Linux inside kvm) doesn't see #GP when guest (lguest, Linux ring 1)
> > invokes KVM_HYPERCALL.  Guest continues execution after hypercall.
> >
> > One solution would be to return to lguest-specific hypercall mechanism, but
> > the faux commonality is cute.
> >
> >    
> 
> The VMCALL documentation says:
> 
> > IF not in VMX operation
> >     THEN #UD;
> > ELSIF in VMX non-root operation
> >     THEN VM exit;
> > ELSIF (RFLAGS.VM = 1) OR (IA32_EFER.LMA = 1 and CS.L = 0)
> >     THEN #UD;
> > ELSIF CPL > 0
> >     THEN #GP(0);
> 
> So there's no reason to expect a #GP if running in a guest.

I assumed, since CPL > 0, we'd hit that #GP.  I don't have my manuals on me,
but It Used To Work.

> Best for performance would be to use SYSCALL/SYSENTER, but that means 
> modifying the ordinary syscall fastpath, which isn't nice.  You could 
> switch the syscall entry point msr, but that's slow.

Yes, and SYSENTER is a mess to handle correctly.  A simple fault is easier,
though slower (we actually rewrite the vmcall as it happens, for speed).

Thanks,
Rusty.