[PATCH v19 2/7] firmware: arm_rmm: Check for RMI support at init

[Suzuki K Poulose]

On 25/09/2026 11:42, Catalin Marinas wrote:
> On Thu, Sep 24, 2026 at 02:51:56PM +0100, Suzuki K Poulose wrote:
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 32102c3912fa7..e8b29983b0021 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -293,6 +293,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar3[] = {
>>   static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>>   	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_EL1_CSV3_SHIFT, 4, 0),
>>   	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_EL1_CSV2_SHIFT, 4, 0),
>> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_EL1_RME_SHIFT, 4, 0),
> 
> I think we end up exposing this to (any) guest unless we mask it out in
> sanitise_id_aa64dfr0_el1(). Do the guests care about the RME version? I

Valid point. I personally don't think this matters. The FEAT_RME alone
is not useful or harmful. I could mask it in KVM as a safe bet.

Cheers
Suzuki

> don't think they should, especially the non-realm ones. For nested it's
> masked away already (limit_nv_id_reg()).
>