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

[Jim Mattson]

On Wed, Apr 15, 2026 at 5:29 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, Apr 15, 2026, Jim Mattson wrote:
> > On Wed, Apr 15, 2026 at 2:26 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > On Thu, Apr 09, 2026, Jim Mattson wrote:
> > > > When would we use the deferred version? As far as the Intel PMU is
> > > > concerned. there's nothing special about a nested transition.
> > >
> > > Actually, outside of VMRUN=>#VMEXIT, isn't the deferred version correct?  E.g.
> > > when counting instructions, shouldn't WRMSR(EFER) be accounted based on the *old*
> > > EFER value, not the new EFER value?
> >
> > Unless you can point to documentation stating otherwise, I think this
> > needs testing. By analogy with VMRUN and #VMEXIT, accounting should be
> > based on the CPU state at instruction retirement.
>
> IMO, VMRUN and #VMEXIT are broken :-)
>
> But yeah, +1 to following what hardware does.  I was thinking we could look at
> our KUT and selftests code, but AFAICT all of the precise measurements are
> bookended by WRMSRs, so an off-by-one on the frontend would be corrected by the
> off-by-one on the backend.

LOL! When EFER.SVME is clear, setting one or both of the G/H bits
disables the counter.

In the following code sequence, 10 instructions are retired, and 5
host-only instructions are retired:

mov    $0xc0000301,%ecx
mov    $0x3,%eax
xor    %edx,%edx
wrmsr
nopl   0x0(%rax,%rax,1)
mov    $0xc0000080,%ecx
mov    %ebx,%eax
mov    %r14d,%edx
wrmsr
nopl   0x0(%rax,%rax,1)
mov    $0xc0000301,%ecx
xor    %eax,%eax
xor    %edx,%edx
wrmsr

I think the first wrmsr counts (because the PGC bits are set when it
retires) and the last one does not (because the PGC bits are clear
when it retires). If so, then the second wrmsr (setting EFER.SVME)
counts in host mode.