Re: [PATCH 9/9] Add VMEXIT handler and intercepts

[Avi Kivity <avi@qumranet.com>]

Alexander Graf wrote:
>>> +        svm->vmcb->control.exit_info_2 = svm->vcpu.arch.cr2;
>>>
>>
>> #vmexit isn't supposed to modify cr2, but we've corrupted it here.
>
> Well, yes and no. We modified the arch.cr2 but later on in vcpu_run we 
> don't set the vmcb cr2 field based on that when we're running inside a 
> VM, so cr2 stays the same as before.

What about later, when there is a virtual #VMEXIT?  Won't that cr2 leak in?

>>> +    /* Kill any pending exceptions */
>>> +    if (svm->vcpu.arch.exception.pending == true)
>>> +        nsvm_printk("WARNING: Pending Exception\n");
>>>
>>
>> This should set control.exit_int_info.
>
> This is more of a fallback. No exceptions should be in "injecting" 
> state on vmexit. That would mean that after an exit that was not 
> handled in the nested VMM we need to inject some exception, which 
> should in almost all cases already raise a #VMEXIT itself. So this 
> should never hit. 

What about, say, #PF on the IDT when attempting to inject an exception?  
We should tell the guest about that so it can reinject the exception 
into its own guest.

-- 
error compiling committee.c: too many arguments to function