On Thu, 2018-08-30 at 05:54 -0700, Sean Christopherson wrote: > On Thu, 2018-08-30 at 03:24 +0300, Liran Alon wrote: > > > > (Sorry for opening a new email thread. Something screwed up in my email client…) > > > > I see a couple of issues with the patch you suggest: > > > > 1. When L1 don’t intercept external-interrupts, interrupt should still be injected after vmlaunch/vmresume but directly to L2. > > Therefore, we should remove the tests against vmcs12->pin_based_vm_exec_control bits. > > (KVM_REQ_EVENT will handle this direct injection to L2 correctly) > Right, not sure why I brought vmcs12 into the picture. The behavior > we're enforcing is the VMExit to L0, everything after that is handled > by whatever normally L0 does after the associated VMExit. > > > > > 2. The logic of deciding if we should set KVM_REQ_EVENT should be inside enter_vmx_non_root_mode() and not nested_vmx_run(). > > This is because otherwise, you could reach a buggy scenario after nVMX migration which sets nVMX state directly from vmx_set_nested_state(). > In that case I think we'd want to nested_run_pending, i.e. entry from > SMM shouldn't set KVM_REQ_EVENT. If nested_run_pending==false and one > of the pending bits is sets (in the migration case) we already goofed. Actually, ignore this. SMI has higher priority so we could be resuming to the first instruction of the guest, at which time the pending INTR/NMI would be taken. > > > > As I agree with you regarding your other comments, I will create a v2 to my patch and submit it. :) > > (Together with the relevant kvm-unit-test) > > > > Thanks, > > -Liran > > > >
