On 5/15/26 5:27 PM, Khushit Shah wrote:
>> On 5/13/26 6:33 PM, Shaju Abraham wrote:
>>> Add a declarative description of every architecturally defined field in the
>>> Arm64 ID registers in cpu-idregs.h.inc file. This file will be included
>>> multiple times with different definitions to build the per-field arch
>>> values,
>>> per-register field descriptor arrays, arm-idregs table etc. The
>>> architecturely
>>> defined values for each ID register field is extracted from kernel's
>>> arch/arm64/tools/sysreg file. The safe-value tags and default values are
>> In the past we were rather advised to use AARCHMRS instead of sysreg.
>> This is what is currently done in [PATCH v4 00/17] kvm/arm: Introduce a
>> customizable aarch64 KVM host model.
> I am not sure if we can get safe rules from AARCHMRS. Otherwise it’s fine.
I don't think it is there.
>
>>> derived from the kernel's ftr_bits array. Aarch32 ID registers are added
>>> with dummy field so they can be defaulted to 0 by later commits.
>>>
>>> X-macro structure:
>>> IDREG_START(REG)
>>> IDREG_FIELD_START(REG, FIELD, SHIFT, LENGTH, SAFE_RULE, DEFAULT_VAL)
>> Why do you need SAFE_RULE/DEFAULT_VAL? As far as I understand this is
>> used when we have different flavours of CPUS in SMP and we face
>> mismatches between CPU features. Why do we care here?
>>
>> I don't see safe_rule used anywhere.
>> I see arm_idregs_reset_to_defaults() uses the default value though.
>> Should we use the Registers.json reset value instead?
> Kernel uses safe_rules to show a common denominator of cpu features in SMP
> and same rules are
> used by KVM to verify if certain field value is valid to show to guest on the
> given host.
> KVM_SET_ONE_REG validates the writable fields with the SAFE_RULE defined in
> ftr_bits table.
OK so you plan to duplicate the logic at both qemu and KVM level. Can't
we simply rely on KVM which already implements that logic. Also if the
check is against a given host, is it relevant here? I need to look again
at the kernel logic though.
>
> So, SAFE_RULE will be used in v2 to validate idregs even before we writeback
> to the KVM, and to
> pass supported field values for a property on a given host to management
> stack (libvirt). Something like
> feat_AES supports (off, aes, pmull) on this host.
>
> Registers.json can probably be used for default_vals, but I will need to
> check further on this.
Registers.json gives the reset value and not the safe value, as far as I
know.
Manual import of those values from the kernel looks tedious and error
prone to me.
Eric
>
> In short: default_vals -> show no feature.
> safe_rule -> valid values for guest given host values.
>
>> taking FHM field if I compare with sysreg I have:
>> UnsignedEnum 51:48 FHM
>> 0b0000 NI
>> 0b0001 IMP
>> 0b0010 F16F32DOT
>> 0b0011 F16F32MM
>> So why do we miss some values?
> The table was created based on sysreg file in 6.18.
> A script added the arch values. Register, Fields, safe values and default
> values are
> maintained manually.
>
> Warm Regards,
> Khushit
>
>
