Re: [PATCH v4 4/8] KVM: x86: nSVM: Redirect IA32_PAT accesses to either hPAT or gPAT

[Sean Christopherson <seanjc@google.com>]

On Fri, Feb 13, 2026, Jim Mattson wrote:
> On Fri, Feb 13, 2026 at 7:20 AM Sean Christopherson <seanjc@google.com> wrote:
> > > > +static inline void svm_set_hpat(struct vcpu_svm *svm, u64 data)
> > > > +{
> > > > +   svm->vcpu.arch.pat = data;
> > > > +   if (npt_enabled) {
> >
> > Peeking at the future patches, if we make this:
> >
> >         if (!npt_enabled)
> >                 return;
> >
> > then we can end up with this:
> >
> >         if (npt_enabled)
> >                 return;
> >
> >         vmcb_set_gpat(svm->vmcb01.ptr, data);
> >         if (is_guest_mode(&svm->vcpu) && !nested_npt_enabled(svm))
> >                 vmcb_set_gpat(svm->nested.vmcb02.ptr, data);
> >
> >         if (svm->nested.legacy_gpat_semantics)
> >                 svm_set_l2_pat(svm, data);
> >
> > Because legacy_gpat_semantics can only be true if npt_enabled is true.  Without
> > that guard, KVM _looks_ buggy because it's setting gpat in the VMCB even when
> > it shouldn't exist.
> >
> > Actually, calling svm_set_l2_pat() when !is_guest_mode() is wrong too, no?  E.g.
> > shouldn't we end up with this?
> 
> Sigh. legacy_gpat_semantics is supposed to be set only when
> is_guest_mode() and nested_npt_enabled(). I forgot about back-to-back
> invocations of KVM_SET_NESTED_STATE. Are there other ways of leaving
> guest mode or disabling nested NPT before the next KVM_RUN?

KVM_SET_VCPU_EVENTS will do it if userspace forces a change in SMM state:

		if (!!(vcpu->arch.hflags & HF_SMM_MASK) != events->smi.smm) {
			kvm_leave_nested(vcpu);
			kvm_smm_changed(vcpu, events->smi.smm);
		}

I honestly wasn't even thinking of anything in particular, it just looked weird.

> > > > +           vmcb_set_gpat(svm->vmcb01.ptr, data);
> > > > +           if (is_guest_mode(&svm->vcpu) && !nested_npt_enabled(svm))
> > > > +                   vmcb_set_gpat(svm->nested.vmcb02.ptr, data);
> > > > +   }
> > > > +}
> > >
> > > Is it me, or is it a bit confusing that svm_set_gpat() sets L2's gPAT
> > > not L1's, and svm_set_hpat() calls vmcb_set_gpat()?
> >
> > It's not just you.  I don't find it confusing per se, more that it's really
> > subtle.
> >
> > > "gpat" means different things in the context of the VMCB or otherwise,
> > > which kinda makes sense but is also not super clear. Maybe
> > > svm_set_l1_gpat() and svm_set_l2_gpat() is more clear?
> >
> > I think just svm_set_l1_pat() and svm_set_l2_pat(), because gpat straight up
> > doesn't exist when NPT is disabled/unsupported.
> 
> My intention was that "gpat" and "hpat" were from the perspective of the vCPU.
> 
> I dislike svm_set_l1_pat() and svm_set_l2_pat(). As you point out
> above, there is no independent L2 PAT when nested NPT is disabled. I
> think that's less obvious than the fact that there is no gPAT from the
> vCPU's perspective. My preference is to follow the APM terminology
> when possible. Making up our own terms just leads to confusion.

How about svm_set_pat() and svm_get_gpat()?  Because hPAT doesn't exist when NPT
is unsupported/disabled, but KVM still needs to set the vCPU's emulated PAT value.