Re: [PATCH v3 04/17] perf: x86/ds: Handle guest PEBS overflow PMI and inject it to guest

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021/1/15 20:01, Peter Zijlstra wrote:
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.

Less overhead makes everyone happier.

Ah, can I assume that you're fine with disabling the
co-existence of guest PEBS and host PEBS as the first upstream step ?


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.

https://lore.kernel.org/lkml/20170628130748.GI5981@leverpostej/T/

In the rr workload, the commit change "the PMI interrupts in skid region should be dropped"
is reverted since some users complain that:

It seems to me that it might be reasonable to ignore the interrupt if
the purpose of the interrupt is to trigger sampling of the CPUs
register state.  But if the interrupt will trigger some other
operation, such as a signal on an fd, then there's no reason to drop
it.

I assume that if the PMI drop is unacceptable, either will spurious PMI injection.

I'm pretty open if you insist that we really need to do this for guest PEBS enabling.


+	 * 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() ?

Sure. Let me try it.

---
thx, likexu




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux