On 5/27/26 4:46 PM, Khushit Shah wrote:
>
>> On 19 May 2026, at 6:57 PM, Eric Auger <[email protected]> wrote:
>>
>>
>> KVM currently reports some bits as writable whereas they are
>> RES0 or RAZ. This is detected because the code attempts to
>> match those bits against a named field and this later does not
>> exist in target/arm/cpu-idregs.h.inc.
>>
>> Let's silence warnings until those bits get fixed in the kernel.
>>
>> This was observed with v7.1-rc4 kernel.
>>
>> Signed-off-by: Eric Auger <[email protected]>
>> ---
>> target/arm/kvm.c | 23 +++++++++++++++++++----
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/target/arm/kvm.c b/target/arm/kvm.c
>> index 6373a66bbd..1688cc2106 100644
>> --- a/target/arm/kvm.c
>> +++ b/target/arm/kvm.c
>> @@ -405,6 +405,19 @@ static void get_sysreg_prop(Object *obj, Visitor *v,
>> trace_get_sysreg_prop(name, value);
>> }
>>
>> +static bool ignore_unnamed_writable_field(ARM64SysReg *reg, int i)
>> +{
>> + if ((!strcmp(reg->name, "ID_ISAR0_EL1") && i >= 28 && i <= 31) || /*
>> RES0 */
>> + (!strcmp(reg->name, "ID_ISAR5_EL1") && i >= 20 && i <= 23) || /*
>> RES0 */
>> + (!strcmp(reg->name, "MVFR2_EL1") && i >= 8 && i <= 31) || /* RES0 */
>> + (!strcmp(reg->name, "ID_PFR2_EL1") && i >= 12 && i <= 31) || /*
>> RES0 */
>> + (!strcmp(reg->name, "ID_MMFR5_EL1") && i >= 8 && i <= 31) || /*
>> RES0 */
>> + (!strcmp(reg->name, "ID_AA64FPFR0_EL1") && i >= 2 && i <= 7)) { /*
>> RAZ */
>> + return true;
>> + }
>> + return false;
>> +}
>> +
>> /*
>> * decode_idreg_writemap: Generate props for writable fields
>> *
>> @@ -426,10 +439,12 @@ decode_idreg_writemap(Object *obj, int index, uint64_t
>> map, ARM64SysReg *reg)
>> uint64_t mask;
>>
>> if (!field) {
>> - warn_report("%s bit %d of %s is writable but no named field "
>> - "in target/arm/cpu-idregs.h.inc",
>> - __func__, i, reg->name);
>> - warn_report("%s is target/arm/cpu-idregs.h.inc?", __func__);
>> + if (!ignore_unnamed_writable_field(reg, i)) {
>> + warn_report("%s bit %d of %s is writable but no named field
>> "
>> + "in target/arm/cpu-idregs.h.inc",
>> + __func__, i, reg->name);
>> + warn_report("%s is target/arm/cpu-idregs.h.inc?", __func__);
>> + }
>> map = map & ~BIT_ULL(i);
>> i = ctz64(map);
>> continue;
>> —
> This is why I feel the generated cpu-idregs.h.inc should also have
> information of
> RES0/1 fields as in our RFC. These fields will obviously have only one
> architecturally
> valid value, hence we will never allow user to write something else.
The good thing is it allowed to detect that kind of kernel inconsistency ;-)
RES fields are not defined either in target/arm/cpu-features.h and since
they are not meant to be touched, it was not that obvious to add them.
What would it change anyway, if we detect we have a writable field
matching a RESx field, I guess we would continue raising a warning, no?
Thanks
Eric
>
> Warm Regards,
> Khushit
