On 19/04/2017 17:33, Jim Mattson wrote: > I think the easiest solution is to allocate a second fixed > notification vector for vmcs02. If the L2 vector arrives while vmcs01 > is active, we suffer an unnecessary VM-exit, but at least if the L1 > vector arrives while vmcs02 is active, we will know to synthesize a > VM-exit from L2 to L1 (if vmcs01's PI descriptor indicates that there > is a virtual interrupt to be delivered). For IPIs it'd be enough to use kvm_vcpu_kick instead of kvm_vcpu_trigger_posted_interrupt when sending an IPI other than the PI vector. Basically we have three cases: - !is_guest_mode, set PIR/ON and either trigger posted interrupt or kick - is_guest_mode, PI vector, set PIR/ON and trigger either posted interrupt or kick (kicking may be necessary when L2 runs under HLT activity state) - is_guest_mode, non PI vector, just kick. kvm_vcpu_running's call to kvm_x86_ops->check_nested_events should handle it just fine: vmx_check_nested_events kvm_cpu_has_interrupt kvm_apic_has_interrupt apic_has_interrupt_for_ppr vmx_sync_pir_to_irr nested_vmx_vmexit On the other hand, I'm not sure how to handle VT-d posted interrupts this way. They would cause a posted interrupt vector IPI, which is then ignored as described in your previous email. Paolo
