[RFC 03/12] KVM: arm64: Hide TLBID from guest sysregs

[Kristina Martšenko]

On Mon, Oct 12, 2026 at 10:12:54AM +0200, Steffen Eiden wrote:
> On Thu, Oct 01, 2026 at 12:06:46PM +0100, Kristina Martšenko wrote:
> > Don't expose FEAT_TLBID to guests. It wouldn't be useful in the general
> > case since a guest doesn't know which domains exist and its vCPUs can be
> > moved between any physical CPUs.
> > 
> > Try to hide TLBID sysregs and sysreg fields from the guest:
> > 
> >   * Report the feature as not supported in the ID register
> >     ID_AA64MMFR4_EL1.TLBID.
> > 
> >   * Configure the TLBIDIDR_EL1 sysreg to UNDEF via the FGU mechanism.
> >     Sanitize a nested hypervisor's HFGRTR2.nTLBIDIDR.
> > 
> >   * Sanitize a nested hypervisor's HCRX.{VTLBIDEn,VTLBIDOSEn,FNB}.
> > 
> >   * VTLBID{OS}<n>_EL2 registers are VNCR-backed and not exposed to
> >     guests (apart from being able to read/write into the VNCR page) so
> >     no need to handle them in sys_reg_descs or elsewhere.
> > 
> >   * The guest is free to set SCTLR2_EL{1,2}.TLBOSNIS, which shouldn't
> >     matter to KVM.
> >
> 
> What confuse me where a bit that you wrote 'try to hide'.
> For me this indicates that the hiding process may not be successful.
> For me the code looks like it will always succeddin hiding the feature
> from the guest, no? Did I miss anything?

Sorry for the vague wording. You’re right that we always succeed in
hiding the feature. What I meant was that there are some parts of the
feature that we can’t fully hide, because the architecture doesn’t
provide a way to do it.

Accessing a VTLBID register should ideally cause an UNDEF exception
(like on a CPU without TLBID), but guest accesses will go to the VNCR
page instead (which won’t have any effect).

> Same for the next patch.

Executing a TLBIP instruction should also UNDEF, but will succeed. There
is no way to trap it without also trapping TLBI instructions.

Thanks,
Kristina