Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [RFC v2] KVM: x86/vmx: Suppress posted interrupt notification when CPU is in host | Date | Wed, 28 Sep 2022 08:29:48 +0000 |
| |
> From: Gao, Chao <chao.gao@intel.com> > Sent: Friday, September 23, 2022 4:58 PM > > PIN (Posted interrupt notification) is useless to host as KVM always syncs > pending guest interrupts in PID to guest's vAPIC before each VM entry. In > fact, Sending PINs to a CPU running in host will lead to additional > overhead due to interrupt handling. > > Currently, software path, vmx_deliver_posted_interrupt(), is optimized to > issue PINs only if target vCPU is in IN_GUEST_MODE. But hardware paths > (VT-d and Intel IPI virtualization) aren't optimized. > > Set PID.SN right after VM exits and clear it before VM entry to minimize > the chance of hardware issuing PINs to a CPU when it's in host. > > Also honour PID.SN bit in vmx_deliver_posted_interrupt(). > > Opportunistically clean up vmx_vcpu_pi_put(); when a vCPU is preempted, > it is pointless to update PID.NV to wakeup vector since notification is > anyway suppressed. And since PID.SN should be already set for running > vCPUs, so, don't set it again for preempted vCPUs. > > When IPI virtualization is enabled, this patch increases "perf bench" [*] > by 6.56%, and PIN count in 1 second drops from tens of thousands to > hundreds. But cpuid loop test shows this patch causes 1.58% overhead in > VM-exit round-trip latency. > > [*] test cmd: perf bench sched pipe -T. Note that we change the source > code to pin two threads to two different vCPUs so that it can reproduce > stable results. > > Signed-off-by: Chao Gao <chao.gao@intel.com> > --- > RFC: I am not sure whether the benefits outweighs the extra VM-exit cost. > > Changes in v2 (addressed comments from Kevin): > - measure/estimate the impact to non-IPC-intensive cases > - don't tie PID.SN to vcpu->mode. Instead, clear PID.SN > right before VM-entry and set it after VM-exit.
One correction here. My comment in v1 [1] was actually close to Sean's suggestion, i.e. opposite to above description:
-- I wonder whether it makes more sense to have 'sn' closely sync-ed with vcpu->mode, e.g. having a kvm_x86_set_vcpu_mode() ops to translate vcpu->mode into vmx/svm specific hardware bits like 'sn' here. Then call it in common place when vcpu->mode is changed. --
[1] https://lore.kernel.org/lkml/BN9PR11MB52766B74ADFBAEC0AA205E298CB39@BN9PR11MB5276.namprd11.prod.outlook.com/
| |