[Lguest] lguest: unhandled trap 13

[Avi Kivity]

On 02/11/2010 08:33 AM, Rusty Russell wrote:
> 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.

The pseudocode is executed top to bottom.  The "VM exit" path is hit first.

> I don't have my manuals on me,
> but It Used To Work.
>    

IIRC we used to inject a #GP in that case.  But that's not guaranteed by 
the documentation.  We could change kvm, but we can't change other 
hypervisors.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.