Re: [PATCH] KVM: SVM: Propagate Translation Cache Extensions to the guest

[Yosry Ahmed]

On Fri, Mar 6, 2026 at 4:56 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Fri, Mar 06, 2026, Yosry Ahmed wrote:
> > > Hrm, I think we should handle all of the kvm_enable_efer_bits() calls that are
> > > conditioned only on CPU support in common code.  While it's highly unlikely Intel
> > > CPUs will ever support more EFER-based features, if they do, then KVM will
> > > over-report support since kvm_initialize_cpu_caps() will effectively enable the
> > > feature, but VMX won't enable the corresponding EFER bit.
> > >
> > > I can't think anything that will go sideways if we rely purely on KVM caps, so
> > > get to something like this as prep work, and then land TCE in common x86?
> >
> > Taking a second look here, doesn't this break the changes introduced
> > by commit 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID checks
> > for host-initiated writes")? Userspace writes may fail if the
> > corresponding CPUID feature is not enabled.
>
> No, because kvm_cpu_cap_has() == boot_cpu_has() filtered by what KVM supports.
> All of these EFER updates subtly rely on KVM enabling the associated CPUID
> feature in kvm_set_cpu_caps().
>
> If we used guest_cpu_cap_has(), then yes, that would be a problem.

Gaah I mixed up guest_cpu_cap_has() and kvm_cpu_cap_has(), sorry for the noise.