Re: [PATCH v1] arm64/mm: Fix Boot panic on Ampere Altra

[Ryan Roberts <ryan.roberts@arm.com>]

On 26/02/2025 08:33, Ard Biesheuvel wrote:
> On Wed, 26 Feb 2025 at 09:07, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>
>> On 26/02/2025 06:59, Ard Biesheuvel wrote:
>>> On Wed, 26 Feb 2025 at 01:10, Will Deacon <will@kernel.org> wrote:
>>>>
>>>> On Tue, Feb 25, 2025 at 07:05:35PM +0100, Ard Biesheuvel wrote:
>>>>> Apologies for the breakage, and thanks for the fix.
>>>>>
>>>>> I have to admit that I was a bit overzealous here: there is no point
>>>>> yet in using the sanitised value, given that we don't actually
>>>>> override the PA range in the first place.
>>
>> But unless I've misunderstood something, parange is overridden; Commit
>> 62cffa496aac (the same one we are fixing) adds an override to force parange to
>> 48 bits when arm64.nolva is specified for LPA2 systems (see mmfr2_varange_filter()).
>>
>> I thought it would be preferable to honour that override, hence my use of
>> arm64_apply_feature_override() in the fix. Are you saying we don't need to worry
>> about that case?
>>
> 
> I wouldn't think so (but I'm glad you brought it up because this
> didn't occur to me at all tbh)
> 
> With arm64.nolva, both the VA and PA ranges will be reduced, and so
> the range of the linear map will be 47 bits. So if the PA range is
> being reduced from 52 to 48, it will still exceed the size of the
> linear map, and so it should make no difference in this particular
> case.

OK, so I think you're saying it'll happen to work correctly even if we ignore
that override? That sounds a bit fragile to me. Surely we should be consistent
and either always honour the override or remove the override in the first place?

> 
> The use case I had in mind was to allow the PA range to be reduced to
> a value that is substantially less than the range of the linear map,
> e.g, 40 bits on a 48-bit VA kernel. On the Android side, the issue of
> the missing linear map randomization has come up a couple of times,
> but there is no clear direction at this point, so adding this feature
> here was premature (mea culpa)