On 5/27/26 6:16 PM, Khushit Shah wrote:
>
>> On 27 May 2026, at 9:31 PM, Eric Auger <[email protected]> wrote:
>>
>> but if a field is RESx why don't you want to overwrite it? Are there
>> cases where a field is RESx depending on a condition?
>>
>> Thanks
>>
>> Eric
>>
> There are cases where fields are RESx based on conditions.
> but too complex to get into those (CCSIDR for e.g.).
>
> What I meant is when we want to realize a model,
> 1. If we don’t account for RESx fields how will we know which fields Res0 or
> Res1.
why would you care. Those fields are not exposed through props so host
has the good value, Res0 or 1, no?
> 2. In future what if RESx field becomes a defined field? Instead of
> maintaining:
>>
>> + 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;
>> + }
but you still have to care with old kernels which expose those fields as
writable. If the value becomes non RESx, you won't have any mismatch
anymore so I think you're just fine. Effectively either we keep this
patch for we just turn the warnings into trace points
Eric
> We can just maintain one cpu-idregs.h.inc and have RESx in that.
>
> Warm Regards,
> Khushit
