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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html