Re: [PATCH v4 3/6] KVM: x86/pmu: Disable counters based on Host-Only/Guest-Only bits in SVM

Yosry Ahmed
2026-04-28T00:37:39Z

On Mon, Apr 27, 2026 at 5:35 PM Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Apr 27, 2026 at 5:34 PM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > On Mon, Apr 27, 2026 at 4:53 PM Sean Christopherson <seanjc@google.com> wrote:
> > >
> > > On Mon, Apr 27, 2026, Yosry Ahmed wrote:
> > > > > We can have our cake and eat it too. Add svm_pmu_handle_nested_transition(),
> > > > > but then also rename and rework reprogram_counters() to support both deferred and
> > > > > synchronous operation, e.g. something like so:
> > > > >
> > > > > ---
> > > > > static inline void __kvm_pmu_reprogram_counters(struct kvm_pmu *pmu, u64 diff,
> > > >
> > > > I don't like 'diff', I think just 'unsigned long *bitmap' and pass a
> > >
> > > Hard no. I agree @diff is a weird name (I was literally just copy+pasting the
> > > existing code), but I _really_ don't like passing a pointer, especially not to
> > > an unsigned long. The bitmap usage throughout the PMU code is mostly internal
> > > implementation details. But for what is reprogram_counters(), and what will be
> > > __kvm_pmu_reprogram_counters(), the "counters to reprogram" is very tightly
> > > coupled to the architectural layout of PERF_GLOBAL_CTRL and PEBS_ENABLED. And
> > > more broadly in the PMU, for the layout of GLOBAL_STATUS_BUFFER_OVF_BIT,
> > > MSR_CORE_PERF_GLOBAL_STATUS, and probably at least one other MSRs. That all
> > > should be captured in the APIs.
> > >
> > > The other reason I don't want to pass a pointer is so that even when the source
> > > _is_ a PMU-internal bitmap, it's super duper obvious that the source bitmap isn't
> > > modified, and that it's operating on a snapshot in time.
> >
> > Sounds good, I will keep u64 (and maybe name it 'counters'), or maybe
> > s64 as that's what kvm_pmu_handle_event() uses (and what the atomic
> > helpers take).
> >
> > >
> > > > bitmap in here like most PMU code?
> > >
> > > FWIW, AFAICT, passing a bitmap as a function argument isn't common at all. I
> > > only see kvm_for_each_pmc() and kvm_pmu_trigger_event() taking a bitmap. There
> > > is a lot of bitmap _usage_, but rarely does KVM pass around a bitmap as a function
> > > argument.
> >
> > We still need to pass a bitmap as an argument to the
> > reprogram_counters() callback that we'll add in
> > kvm_pmu_handle_event(), or would you rather we cast the bitmap to s64
> > here as well?
>
> Hmm I think we should pass the bitmap as-is, otherwise we'll cast it
> back when calling kvm_for_each_pmc().

intel_pmu_cross_mapped_check() actually does this. I will pass in a
s64 and cast it in this case.