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

[Avi Kivity <avi@qumranet.com>]

Alexander Graf wrote:
>
> On Sep 3, 2008, at 11:23 AM, Avi Kivity wrote:
>
>> 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?
>
> The cr2 value would leak into the level1 guest that can't rely on CR2 
> to be correct anyways.

That's not very nice.

>
>>
>>
>>>>> +    /* 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.
>
> Doesn't the CPU already does this for us? When the guest VMM wants to 
> inject an interrupt/exception, that would result in a real injection. 

It could be an exception initiated by the CPU (say, divide overflow) or 
an exception initiated by the guest VMM.

> So when we get a #PF on the IDT the real CPU already filled 
> exit_int_info for us and we can just pass it on to the guest VMM...
>

We might be emulating a nested guest instruction, and injecting some 
expection.

> I can't think of a situation where we inject a #PF and did not get a 
> #VMEXIT from a #PF before that.

I'm confused...

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