On 30 October 2017 at 15:13, Heyi Guo <[email protected]> wrote: > Hi Ard, > > > On 10/30/2017 04:21 PM, Ard Biesheuvel wrote: >> >> On 30 October 2017 at 03:52, Heyi Guo <[email protected]> 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. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
