On 2013-02-20 16:57, Gleb Natapov wrote: > On Wed, Feb 20, 2013 at 04:51:39PM +0100, Jan Kiszka wrote: >> On 2013-02-20 16:30, Gleb Natapov wrote: >>> On Wed, Feb 20, 2013 at 03:53:53PM +0100, Jan Kiszka wrote: >>>> On 2013-02-20 14:01, Jan Kiszka wrote: >>>>> This aligns VMX more with SVM regarding event injection and recovery for >>>>> nested guests. The changes allow to inject interrupts directly from L0 >>>>> to L2. >>>>> >>>>> One difference to SVM is that we always transfer the pending event >>>>> injection into the architectural state of the VCPU and then drop it from >>>>> there if it turns out that we left L2 to enter L1. >>>>> >>>>> VMX and SVM are now identical in how they recover event injections from >>>>> unperformed vmlaunch/vmresume: We detect that VM_ENTRY_INTR_INFO_FIELD >>>>> still contains a valid event and, if yes, transfer the content into L1's >>>>> idt_vectoring_info_field. >>>>> >>>>> To avoid that we incorrectly leak an event into the architectural VCPU >>>>> state that L1 wants to inject, we skip cancellation on nested run. >>>>> >>>>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >>>>> --- >>>>> >>>>> Survived moderate testing here and (currently) makes sense to me, but >>>>> please review very carefully. I wouldn't be surprised if I'm still >>>>> missing some subtle corner case. >>>> >>>> Forgot to point this out again: It still takes "KVM: nVMX: Fix injection >>>> of PENDING_INTERRUPT and NMI_WINDOW exits to L1" to make L0->L2 >>>> injection work. So this patch logically depends on it. >>>> >>> But this patch has hunks from that patch. >> >> Not mechanically. >> > What do you mean? You can apply them in arbitrary order, just minor offset shifts will be the result. > >> If you prefer me merging them together, let me know. >> > For review not necessary, for applying preferably. OK, will wait for review on this, then send out a combo patch. 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
