Re: [RFC] Exposing arm64 ID-register safe_rules semantics to userspace?

[Marc Zyngier <maz@kernel.org>]

On Mon, 08 Jun 2026 14:28:13 +0100,
Khushit Shah <khushit.shah@nutanix.com> wrote:
> > On 8 Jun 2026, at 4:40 PM, Marc Zyngier <maz@kernel.org> wrote:
> > 
> > My question above still stands: why isn't knowing that a field is
> > writable or not, together with the max value of that field, enough to
> > decide what is possible to be set for that field?
> 
> Okay, makes sense, there are 57 fields in cpufeatures.c that are not
> unsigned FTR_LOWER_SAFE. 
> 
> Right now, only 21 of those are writable. 8 of those are single bit,
> with FTR_EXACT and safe_value as 0, so no special case for them.
> 
> So, only special handling for 13 fields are needed for now:
> 
> EXACT: 4 (TGRAN*_2, L1Ip)
> SIGNED_LOWER_SAFE: 7 (TGRAN4, TGRAN64, InnerShr, OuterShr, DoubleLock, PMUVer, PerfMon)
> HIGHER_SAFE: 2 (SpecSEI)
> 
> Hardcoding these 13 works for today’s kernel. But when new fields are made
> writable or are added to ftr_bits, older VMM will by default make assumption
> of them as LOWER_SAFE, which might be wrong.

Hardcoding *anything* feels very wrong. Each of these features is
handled differently for a number of reasons that are related to the
architecture itself and the way the kernel is using it *for itself*.
This information is not supposed to be consumed by userspace, and is
not exposed to it.

The problem you seem to have here is that you want to deal with these
features without capturing any understanding of what these actually
mean in the context of the architecture. I can't see a good outcome of
that sort of thing in the long run. The VMM is, for better or worse,
part of the overall hypervisor. It cannot treat the features as a bag
of bits.

This is also why the whole "CPU model" thing is IMO a bad idea: it is
syntactic sugar that falls at the first hurdle, simply because the
architecture is not fully virtualisable. For example you can't take a
Neoverse V2 description and apply it to a KVM guest running on V2 HW.

I think you need to revisit your approach to this stuff.

	M.

-- 
Without deviation from the norm, progress is not possible.