On Mon, Apr 15, 2024, Mingwei Zhang wrote:There is similar issue on LoongArch vPMU where vm can directly pmu hardware and pmu hw is shard with guest and host. Besides context switch there are other places where perf core will access pmu hw, such as tick timer/hrtimer/ipi function call, and KVM can only intercept context switch.
On Mon, Apr 15, 2024 at 10:38 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
One my biggest complaints with the current vPMU code is that the roles and
responsibilities between KVM and perf are poorly defined, which leads to suboptimal
and hard to maintain code.
Case in point, I'm pretty sure leaving guest values in PMCs _would_ leak guest
state to userspace processes that have RDPMC permissions, as the PMCs might not
be dirty from perf's perspective (see perf_clear_dirty_counters()).
Blindly clearing PMCs in KVM "solves" that problem, but in doing so makes the
overall code brittle because it's not clear whether KVM _needs_ to clear PMCs,
or if KVM is just being paranoid.
So once this rolls out, perf and vPMU are clients directly to PMU HW.
I don't think this is a statement we want to make, as it opens a discussion
that we won't win. Nor do I think it's one we *need* to make. KVM doesn't need
to be on equal footing with perf in terms of owning/managing PMU hardware, KVM
just needs a few APIs to allow faithfully and accurately virtualizing a guest PMU.
Faithful cleaning (blind cleaning) has to be the baseline
implementation, until both clients agree to a "deal" between them.
Currently, there is no such deal, but I believe we could have one via
future discussion.
What I am saying is that there needs to be a "deal" in place before this code
is merged. It doesn't need to be anything fancy, e.g. perf can still pave over
PMCs it doesn't immediately load, as opposed to using cpu_hw_events.dirty to lazily
do the clearing. But perf and KVM need to work together from the get go, ie. I
don't want KVM doing something without regard to what perf does, and vice versa.