[PATCH] arm64: mm: set ZONE_DMA size based on early IORT scan

[Robin Murphy]

On 2020-10-13 14:42, Ard Biesheuvel wrote:
> On Tue, 13 Oct 2020 at 15:13, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
>>
>> On Tue, Oct 13, 2020 at 01:22:32PM +0200, Ard Biesheuvel wrote:
>>
>> [...]
>>
>>>>> diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst
>>>>> index 47ecb9930dde..947f5b5c45ef 100644
>>>>> --- a/Documentation/arm64/arm-acpi.rst
>>>>> +++ b/Documentation/arm64/arm-acpi.rst
>>>>> @@ -205,6 +205,13 @@ devices available.  This list of tables is not meant to be all inclusive;
>>>>>   in some environments other tables may be needed (e.g., any of the APEI
>>>>>   tables from section 18) to support specific functionality.
>>>>>
>>>>> +It is assumed that all DMA capable devices in the system are able to
>>>>> +access the lowest 4 GB of system memory. If this is not the case, an
>>>>> +IORT describing those limitations is mandatory, even if an IORT is not
>>>>> +otherwise necessary to describe the I/O topology, and regardless of
>>>>> +whether _DMA methods are used to describe the DMA limitations more
>>>>> +precisely. Once the system has booted, _DMA methods will take precedence
>>>>> +over DMA addressing limits described in the IORT.
>>>>
>>>> If this is a boot requirement it must be in ARM's official documentation,
>>>> first, not the kernel one.
>>>>
>>>> I understand this is an urgent (well - no comments on why bootstrapping
>>>> ACPI on Raspberry PI4 is causing all this fuss, honestly) fix but that's
>>>> not a reason to rush through these guidelines.
>>>>
>>>> I would not add this paragraph to arm-acpi.rst, yet.
>>>>
>>>
>>> Which documentation? ACPI compliance by itself is not sufficient for a
>>> system to be able to boot Linux/arm64, which is why we documented the
>>> requirements for ACPI boot on Linux/arm64 in this file. I don't think
>>> we need endorsement from ARM to decide that odd platforms like this
>>> need to abide by some additional rules if they want to boot in ACPI
>>> mode.
>>
>> I think we do - if we don't we should not add this documentation either.
>>
>> ACPI on ARM64 software stack is based on standardized HW requirements.
>> The sheer fact that we need to work around a HW deficiency shows that
>> either this platform should have never been booted with ACPI or the _HW_
>> design guidelines (BSA) are not tight enough.
>>
>> Please note that as you may have understood I asked if we can implement
>> a workaround in IORT because that's information that must be there
>> regardless (and an OEM ID match in arch code - though pragmatic -
>> defeats the whole purpose), I don't think we should tell Linux kernel
>> developers how firmware must be written to work around blatantly
>> non-compliant systems.
>>
> 
> This is not about systems being compliant or not, unless there is a
> requirement somewhere that I missed that all masters in the system
> must be able to access at least 32 bits of DMA.
> 
> The problem here is that Linux/arm64 cannot deal with fully compliant
> systems that communicate their [permitted] DMA limitations via a _DMA
> method if this limitation happens to be that the address limit < 32
> bits. The DMA subsystem can deal with this fine, only the default DMA
> zone sizing policy creates an internal issue where the DMA subsystem
> is not able to allocate memory that matches the DMA constraints.
> 
> So the 'correct' fix here would be to rework the memory allocator so
> it can deal with arbitrary DMA limits at allocation time, so that any
> limit returned by a _DMA method can be adhered to on the fly.

Yup, it's a shame that [1] apparently never got anywhere. I believe that 
killing off the DMA zones is still something we'd like to work towards 
(or at least I hope it is...) but I doubt we're going to get there very 
soon.

Robin.

[1] https://lore.kernel.org/lkml/200803071007.493903088@firstfloor.org/

> However, we all agree that the Raspberry Pi4 is not worth that effort,
> and that in the general case, SoCs with such limitations, even if they
> are compliant per the spec, are not worth the trouble of complicating
> this even more. So as a compromise, I think it is perfectly reasonable
> to require that systems that have such limitations communicate them
> via the IORT, which we can parse early, regardless of whether _DMA
> methods exist as well, and whether they return the same information.
> 
> So this is not a requirement on arm64 ACPI systems in general. It is a
> requirement that expresses that we, as arm64
> contributors/[co-]maintainers, are willing to cater for such systems
> if they implement their firmware in a particular way.
>