Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 30 October 2017 at 15:13, Heyi Guo <heyi.guo@linaro.org> wrote:
> Hi Ard,
>
>
> On 10/30/2017 04:21 PM, Ard Biesheuvel wrote:
>>
>> On 30 October 2017 at 03:52, Heyi Guo <heyi.guo@linaro.org> wrote:
>>>
>>> Hi folks,
>>>
>>> In NonDiscoverablePciDeviceDxe driver, NonCoherentPciIoAllocateBuffer may
>>> allocate EFI_MEMORY_UC buffer depending on input Attributes and GCD
>>> capabilities. If it does, it actually allocates memory of "device" type
>>> in
>>> AArch64, but not "normal uncacheable" memory. For "device" memory type,
>>> it
>>> requires restrict access alignment and it may trigger alignment fault
>>> exception with BaseMemoryLibOptDxe in which read/write alignment is not
>>> guaranteed.
>>>
>>> Is EFI_MOMORY_WC enough for AArch64 platforms? How about other platforms,
>>> like X86?
>>>
>> Hello Heyi,
>>
>> Do you mean EFI_MEMORY_UC in the last sentence? If not, I don't
>> understand the question.
>
> I actually meant EFI_MOMORY_WC for I supposed EFI_MOMORY_WC should be enough
> for AArch64 non cacheable DMA access.
>
>>
>> Anyway, in reality, this code will only allocate EFI_MEMORY_UC memory
>> if any memory already exists in the memory map with that capability,
>> otherwise it will fall back to EFI_MEMORY_WC. On most arm64 platforms,
>> we no longer add this capability to system memoryEFI_MOMORY_WC by default,
>> so you
>> should be getting EFI_MEMORY_WC in most cases.
>
>
> Oh, I supposed we always have UC capability for system memory and we
> actually still do that on D0x platforms. Does it mean we'd better remove
> this capability to get the issue fixed?

Yes.

> Is there any architectural reason
> for not setting UC capability on system memory?
>

Yes, exactly the reasons you mention: memory no longer behaves as
memory if you map it with EFI_MEMORY_UC attributes, i.e., unaligned
accesses or DC ZVA instructions can no longer be used.