On Thu, Jan 14, 2021 at 11:39:00AM +0800, Xu, Like wrote: > > Why do we need to? Can't we simply always forward the PMI if the guest > > has bits set in MSR_IA32_PEBS_ENABLE ? Surely we can access the guest > > MSRs at a reasonable rate.. > > > > Sure, it'll send too many PMIs, but is that really a problem? > > More vPMI means more guest irq handler calls and > more PMI virtualization overhead. Only if you have both guest and host PEBS. And in that case I really can't be arsed about some overhead to the guest. > In addition, > the correctness of some workloads (RR?) depends on > the correct number of PMIs and the PMI trigger times > and virt may not want to break this assumption. Are you sure? Spurious NMI/PMIs are known to happen anyway. We have far too much code to deal with them. > > > + * If PEBS interrupt threshold on host is not exceeded in a NMI, there > > > + * must be a PEBS overflow PMI generated from the guest PEBS counters. > > > + * There is no ambiguity since the reported event in the PMI is guest > > > + * only. It gets handled correctly on a case by case base for each event. > > > + * > > > + * Note: KVM disables the co-existence of guest PEBS and host PEBS. > > Where; I need a code reference here. > > How about: > > Note: KVM will disable the co-existence of guest PEBS and host PEBS. > In the intel_guest_get_msrs(), when we have host PEBS ctrl bit(s) enabled, > KVM will clear the guest PEBS ctrl enable bit(s) before vm-entry. > The guest PEBS users should be notified of this runtime restriction. Since you had me look at that function, can clean up that CONFIG_RETPOLINE crud and replace it with static_call() ?
