> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] > Sent: Wednesday, September 28, 2016 6:17 PM > To: Wu, Feng <feng.wu@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; > kvm@xxxxxxxxxxxxxxx > Cc: yang.zhang.wz@xxxxxxxxx; mst@xxxxxxxxxx; rkrcmar@xxxxxxxxxx > Subject: Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv > interrupt injection > > > > On 28/09/2016 12:04, Wu, Feng wrote: > > > > > >> -----Original Message----- > >> From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo > >> Bonzini > >> Sent: Wednesday, September 28, 2016 5:20 AM > >> To: linux-kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx > >> Cc: yang.zhang.wz@xxxxxxxxx; Wu, Feng <feng.wu@xxxxxxxxx>; > >> mst@xxxxxxxxxx; rkrcmar@xxxxxxxxxx > >> Subject: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv > interrupt > >> injection > >> > >> Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU > >> is blocked", 2015-09-18) the posted interrupt descriptor is checked > >> unconditionally for PIR.ON. Therefore we don't need KVM_REQ_EVENT to > >> trigger the scan and, if NMIs or SMIs are not involved, we can avoid > >> the complicated event injection path. > > > > But the following code still remains in the KVM_REQ_EVENT checking part: > > > > if (kvm_lapic_enabled(vcpu)) { > > update_cr8_intercept(vcpu); > > kvm_lapic_sync_to_vapic(vcpu); > > } > > > > Does this matter? > > Good question, but it doesn't matter for APICv because: > > - update_cr8_intercept is disabled if APICv, see vmx.c: > > if (enable_apicv) > kvm_x86_ops->update_cr8_intercept = NULL; Which tree are you using, I am using linux kernel tree with Linux 4.8-rc7, and I only see the following code in vmx.c if(!cpu_has_vmx_tpr_shadow()) kvm_x86_ops->update_cr8_intercept = NULL; > > - kvm_lapic_sync_to_vapic's call to apic_sync_pv_eoi_to_guest is also > disabled if APICv: > > if (!pv_eoi_enabled(vcpu) || > apic->irr_pending || > apic->highest_isr_cache == -1 || > kvm_ioapic_handles_vector(apic, apic->highest_isr_cache)) > return; > > (highest_isr_cache is always -1 for APICv) > > - The TPR/ISR/IRR shadow that kvm_lapic_sync_to_vapic writes is only > read by the paravirtualized TPR access code in the vAPIC ROM > (pc-bios/optionrom/kvmvapic.S in the QEMU tree). That code never runs if > you don't get TPR access vmexits, and indeed TPR access vmexits never > happen if KVM uses APICv (or even only the old-style TPR shadowing). Good to know this, thanks for sharing! Thanks, Feng -- 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
