On Fri, Apr 21, 2017 at 3:57 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 21/04/2017 04:51, Wincy Van wrote: >> On Wed, Apr 19, 2017 at 11:33 PM, Jim Mattson <jmattson@xxxxxxxxxx> 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). >>> >> I also prefer this solution. >> >> Assume that the new PI vector is pi_vec02, and the old vector is pi_vec01. >> We just need to use pi_vec02 and pi_vec01 to set POSTED_INTR_VECTOR >> field in prepare_vmcs02/prepare_vmcs12. >> Then, use the corresponding pi_vec01/pi_vec02 to trigger PI when dest >> vcpu ! is_guest_mode / is_guest_mode. >> >> If dest vcpu is_guest_mode, when L1 is sending IPI, we are going to >> use pi_vec01, and a nested vmexit >> will be triggered in vmx_check_nested_events. >> >> Paolo, I think may be the VT-d PI will also be handled in this solution ? > > Yes, it would. I thought more about the VT-d PI and I didn't find an > efficient way to fix it with one vector. Wincy, would you like to write > the patch? > Certainly, will do it next week. Thanks, Wincy
