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

[Marc Zyngier <maz@kernel.org>]

On Fri, 16 Oct 2026 10:07:37 +0100,
Khushit Shah <khushit.shah@nutanix.com> wrote:
> 
> I take your point that a named model cannot be a faithful Neoverse V2
> (or any other) TRM view: even on V2 hardware, a KVM guest only gets
> the subset that the architecture and KVM can actually virtualise. We
> are not trying to present a TRM-accurate Neoverse V2 to the guest.
> 
> What we are after is a migration ABI: a fixed guest-visible ID register
> contract that stays identical across all hosts capable of running it.

That ABI exists. It is probably buggy as hell, but it is there at
least in principles.

> In my research so far, I have identified the following pitfalls with
> this approach:
> 
> - Guest errata: errata handling in the guest is driven by MIDR/REVIDR,
>   so if those do not match the real host, the guest can pick the wrong
>   workarounds or skip needed ones.
> 
>   Shameer's errata-management work, where the VMM gives the guest the
>   list of target implementations could address this.
> 
> - PMU: events and counters are core-specific, so they cannot be
>   supported reliably across heterogeneous hosts.
> 
>   We currently leave PMU out of named models for that reason.

This is a deal breaker IMO. Most interesting events are *architected*,
and SW that relies on non-architectural events has bigger problems
anyway (i.e. it is never able to migrate correctly). Removing PMU
support from named models on these grounds is yet another nail on that
coffin.

The "better" thing to do is to list the events you want to support and
use the event filter to reject anything else.

> - IMP-DEF registers: ACTLR_EL1, AMAIR_EL1 and AFSR0/1_EL1 are the
>   trickiest in principle. A named model should only be allowed to boot
>   on hosts where these registers have the same semantics as on the
>   implementation the model's MIDR describes.
> 
>   Would it make sense for KVM to make them RAZ/WI instead? AFAIU, they
>   are rarely used by guests; mainline Linux does not touch them at all.

ACTLR_EL1 is treated as WI already, but will report the value the
physical CPU has. We don't know if it is safe to have anything else.
It may have been yet another early misdesign to do so, but we can't
change this behaviour now.

Trapping the other registers to make them RAZ/WI requires trapping all
VM related registers on CPUs that do not have FEAT_FGT (see the
registers trapped by HCR_EL2.TVM to get an idea). The cost of that is
simply not acceptable.

And to be clear: an implementation that associates non-architectural
behaviours to these registers is not virtualisable, and will break
under migration. There is nothing that SW can do about it, because the
hardware is fundamentally misdesigned when it comes to virtualisation.

But we're pretty far from named models anyway.

	M.

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