Re: [PATCH] KVM: nVMX: Fix direct injection of interrupts from L0 to L2

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-02-19 17:14, Joerg Roedel wrote:
> On Tue, Feb 19, 2013 at 11:04:01AM +0100, Jan Kiszka wrote:
>> I had a look at SVM to check how it deals with this, but I'm not sure
>> if I understand the logic correctly. SVM does:
>>
>> static int nested_svm_vmexit(struct vcpu_svm *svm)
>> {
>> 	...
>> 	/*
>> 	 * If we emulate a VMRUN/#VMEXIT in the same host #vmexit cycle we have
>> 	 * to make sure that we do not lose injected events. So check event_inj
>> 	 * here and copy it to exit_int_info if it is valid.
>> 	 * Exit_int_info and event_inj can't be both valid because the case
>> 	 * below only happens on a VMRUN instruction intercept which has
>> 	 * no valid exit_int_info set.
>> 	 */
>> 	if (vmcb->control.event_inj & SVM_EVTINJ_VALID) {
>> 		struct vmcb_control_area *nc = &nested_vmcb->control;
>>
>> 		nc->exit_int_info     = vmcb->control.event_inj;
>> 		nc->exit_int_info_err = vmcb->control.event_inj_err;
>> 	}
>>
>> nested_svm_vmexit is only called when we leave L2 toward L1, right?
> 
> Right.
> 
>> So, vmcb->control.event_inj might have been set on last VMRUN emulation, and
>> if that one failed, this value shall become the nested exit_int_info. So
>> far, so good.
> 
> Important fact here: This L2->L1 exit is emulated in the same real
> #vmexit cycle as the VMRUN was emulated. So what happens is:
> 
> 	1. VMRUN intercept from L1
> 	2. We emulate the VMRUN and load L2 state into VMCB
> 	3. On the way back to guest mode (to actually run the L2) we
> 	   detect a #vmexit condition
> 	4. So we roll-back by calling nested_svm_vmexit()
> 	5. We enter the guest again which continues execution right
> 	   after its VMRUN instruction.
> 
> So we never actually entered L2, but for L1 it has to look like it was
> in L2 and made no progress. But when coming out of a guest event_inj is
> never valid, so without the special case above we make sure that the L1
> hypervisor re-injects the event so it is not lost.

Thanks for explaining. Already assumed this in my other mail. Makes
perfect sense now.

Need to rethink if / how this maps on VMX and if there is something
special on that side.

> 
> 
>> But what if that injection succeeded and we are now exiting L2 past the
>> execution of VMRUN, e.g. L1 intercepts the execution of some special
>> instruction in L2? Doesn't the nested exit_int_info now gain a stale
>> value? Or does the hardware clear the valid bit int EVENTINJ on
>> successful injection? Didn't find an indication in the spec on first
>> glance.
> 
> Hardware clears event_inj. If the injection was not successful the event
> is reported in exit_int_info.
> 
>> Otherwise the logic seems to be like this:
>>  - EVENTINJ is set to the nested value on VMRUN emulation, and only
>>    there (that's in contrast to current VMX, but it makes sense)
>>  - Interrupt completion with state transfer the VCPU event queues is
>>    *only* performed on L2-to-L1 exits (that's like VMX is trying to do
>>    it as well)
>>  - There is a special case around nested.exit_required that I didn't
>>    fully get yet, nor can I say how it corresponds to logic in VMX.
> 
> Which special case do you mean? There are checks in
> nested_svm_check_exception() and nested_svm_intr().

What you explained above. It wasn't clear for me at that point when
exit_required is set and what the implications are.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux