Re: [PATCH v4 4/6] KVM: x86/pmu: Re-evaluate Host-Only/Guest-Only on nested SVM transitions

[Sean Christopherson]

On Wed, Apr 08, 2026, Jim Mattson wrote:
> On Wed, Mar 25, 2026 at 8:12 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
> > index bdbe0456049d0..fb73806d3bfa0 100644
> > --- a/arch/x86/kvm/pmu.h
> > +++ b/arch/x86/kvm/pmu.h
> > @@ -248,6 +248,19 @@ static inline bool kvm_pmu_is_fastpath_emulation_allowed(struct kvm_vcpu *vcpu)
> >                                   X86_PMC_IDX_MAX);
> >  }
> >
> > +static inline void kvm_pmu_handle_nested_transition(struct kvm_vcpu *vcpu)
> > +{
> > +       struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> > +
> > +       if (bitmap_empty(pmu->pmc_needs_nested_reprogram, X86_PMC_IDX_MAX))
> > +               return;
> > +
> > +       BUILD_BUG_ON(sizeof(pmu->pmc_needs_nested_reprogram) != sizeof(atomic64_t));
> > +       atomic64_or(*(s64 *)pmu->pmc_needs_nested_reprogram,
> > +                   &vcpu_to_pmu(vcpu)->__reprogram_pmi);
> > +       kvm_make_request(KVM_REQ_PMU, vcpu);
> > +}
> 
> In general, this deferral is misguided. The G/H bits should be
> re-evaluated before we call kvm_pmu_instruction_retired() for an
> emulated instruction.
> 
> > ...
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index f1c29ac306917..966e4138308f6 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -9,6 +9,7 @@
> >  #include "kvm_cache_regs.h"
> >  #include "kvm_emulate.h"
> >  #include "cpuid.h"
> > +#include "pmu.h"
> >
> >  #define KVM_MAX_MCE_BANKS 32
> >
> > @@ -152,6 +153,8 @@ static inline void enter_guest_mode(struct kvm_vcpu *vcpu)
> >  {
> >         vcpu->arch.hflags |= HF_GUEST_MASK;
> >         vcpu->stat.guest_mode = 1;
> > +
> > +       kvm_pmu_handle_nested_transition(vcpu);
> >  }
> 
> This happens too late for VMRUN, since we have already called
> kvm_pmu_instruction_retired() via kvm_skip_emulated_instruction(), and
> VMRUN counts as a *guest* instruction.

It's just VMRUN that's problematic though, correct?  I.e. the scheme as a whole
is fine, we just need to special case VMRUN due to SVM's erratum^Warchitecture.
Alternatively, maybe we could get AMD to document the silly VMRUN behavior as an
erratum, then we could claim KVM is architecturally superior. :-D