On 2021/1/15 22:46, Peter Zijlstra wrote:
On Mon, Jan 04, 2021 at 09:15:31PM +0800, Like Xu wrote:
+ if (cpuc->pebs_enabled & ~cpuc->intel_ctrl_host_mask) {
+ arr[1].msr = MSR_IA32_PEBS_ENABLE;
+ arr[1].host = cpuc->pebs_enabled & ~cpuc->intel_ctrl_guest_mask;
+ arr[1].guest = cpuc->pebs_enabled & ~cpuc->intel_ctrl_host_mask;
+ /*
+ * The guest PEBS will be disabled once the host PEBS is enabled
+ * since the both enabled case may brings a unknown PMI to
+ * confuse host and the guest PEBS overflow PMI would be missed.
+ */
+ if (arr[1].host)
+ arr[1].guest = 0;
+ arr[0].guest |= arr[1].guest;
+ *nr = 2;
Elsewhere you write:
When we have a PEBS PMI due to guest workload and vm-exits,
the code path from vm-exit to the host PEBS PMI handler may also
bring PEBS PMI and mark the status bit. The current PMI handler
can't distinguish them and would treat the later one as a suspicious
PMI and output a warning.
So the reason isn't that spurious PMIs are tedious, but that the
hardware is actually doing something weird.
Or am I not reading things straight?
I think the PEBS facility works as expected because in the both enabled case,
the first PEBS PMI is generated from host counter 1 based on guest
interrupt_threshold
and the later PEBS PMI could be generated from host counter 2 based on host
interrupt_threshold.
Therefore, if we adjust the overflow value to a small value, so that the
number of
instructions from vm-exit to global ctrl disabling could be enough big to
trigger PEBS PMI.
Do you think this is weird, or do you see other possibilities ?
