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

[Marc Zyngier <maz@kernel.org>]

On Mon, 08 Jun 2026 10:43:11 +0100,
Khushit Shah <khushit.shah@nutanix.com> wrote:
> 
> Hi all,
> 
> On KVM_SET_ONE_REG for ID registers, KVM validates the requested
> field values against the host's values using the per-field rules
> in arm64_ftr_bits[](arch/arm64/kernel/cpufeature.c) (and, some
> KVM specific overrides on top);
>
> In our QEMU RFC for named ARM CPU models [1], we use the safe_rules to:
> - pre-validate a guest ID register configuration before KVM write back,

Pre-validate *how*?

> - report blockers in QMP query-cpu-definitions for a given named
> model,

Sorry, but I have no idea what this is.

> - enumerate supported values per field for QMP/libvirt/upper layers.
>
> RFC has a hand-maintained copy of safe_rules in QEMU that mirrors
> the kernel.
> 
> Any advice for VMMs on how to track the safe_rules used by KVM to
> validate ID-register field values written by userspace?

Why should the VMM care? Either a field is exposed as writable, and in
general it is safe to expose something "lower" than the host value to
the guest, or it isn't, and only that particular value is possible.

There is a few exceptions to this rule, but I expect this to be the
minority.

> 
> There is no API that exposes those rules to VMMs. Until a VMM issues
> KVM_SET_ONE_REG, it cannot know whether the requested set of values
> will be accepted. On failure, VMM still cannot know the faulting field.
>
> We'd like to know what the right approach is:
> - Should there be a KVM ioctl that exposes the safe_rules to
> userspace?
> Maybe Something like KVM_GET_SAFE_RULE (that takes reg_idx and
> start_bit_pos)
> or a bulk ioctl like KVM_GET_REG_SAFE_RULES (that returns (reg_idx,
> start_bit, width, safe_rule, safe_vals) for all the ID registers?
> - Is it acceptable to keep mirroring ftr_bits[] in userspace?
> - Or is this simply not meant to be exposed to userspace VMMs?

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?

Thanks,

	M.

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