Hi Ard,
On 10/30/2017 04:21 PM, Ard Biesheuvel wrote:
On 30 October 2017 at 03:52, Heyi Guo <heyi....@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? Is there any architectural
reason for not setting UC capability on system memory?
Thanks,
Heyi
So the question is actually the opposite: does this interfere with
correct operation in cases where the shared mapping between the CPU
and the device should be strongly ordered, and EFI_MEMORY_WC doesn't
give sufficient guarantees.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
