On Mon, Apr 15, 2024, Mingwei Zhang wrote: > 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, i.e. I don't want KVM doing something without regard to what perf does, and vice versa.
