* [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 @ 2017-10-30 3:52 Heyi Guo 2017-10-30 8:21 ` Ard Biesheuvel 0 siblings, 1 reply; 5+ messages in thread From: Heyi Guo @ 2017-10-30 3:52 UTC (permalink / raw) To: edk2-devel@lists.01.org, Linaro UEFI Mailman List, Ard Biesheuvel, Leif Lindholm, Ni, Ruiyu 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? Thanks and regards, Heyi Guo ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 2017-10-30 3:52 [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 Heyi Guo @ 2017-10-30 8:21 ` Ard Biesheuvel 2017-10-30 15:13 ` Heyi Guo 0 siblings, 1 reply; 5+ messages in thread From: Ard Biesheuvel @ 2017-10-30 8:21 UTC (permalink / raw) To: Heyi Guo Cc: edk2-devel@lists.01.org, Linaro UEFI Mailman List, Leif Lindholm, Ni, Ruiyu 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. 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 memory by default, so you should be getting EFI_MEMORY_WC in most cases. 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. -- Ard. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 2017-10-30 8:21 ` Ard Biesheuvel @ 2017-10-30 15:13 ` Heyi Guo 2017-10-30 15:17 ` Ard Biesheuvel 0 siblings, 1 reply; 5+ messages in thread From: Heyi Guo @ 2017-10-30 15:13 UTC (permalink / raw) To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, Linaro UEFI Mailman List, Leif Lindholm, Ni, Ruiyu 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? 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. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 2017-10-30 15:13 ` Heyi Guo @ 2017-10-30 15:17 ` Ard Biesheuvel 2017-10-31 15:25 ` Heyi Guo 0 siblings, 1 reply; 5+ messages in thread From: Ard Biesheuvel @ 2017-10-30 15:17 UTC (permalink / raw) To: Heyi Guo Cc: edk2-devel@lists.01.org, Linaro UEFI Mailman List, Leif Lindholm, Ni, Ruiyu 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 2017-10-30 15:17 ` Ard Biesheuvel @ 2017-10-31 15:25 ` Heyi Guo 0 siblings, 0 replies; 5+ messages in thread From: Heyi Guo @ 2017-10-31 15:25 UTC (permalink / raw) To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, Linaro UEFI Mailman List, Leif Lindholm, Ni, Ruiyu OK, we'll make the change for D0x too. Thanks, Heyi On 30 October 2017 at 23:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > 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. > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-10-31 15:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-10-30 3:52 [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 Heyi Guo 2017-10-30 8:21 ` Ard Biesheuvel 2017-10-30 15:13 ` Heyi Guo 2017-10-30 15:17 ` Ard Biesheuvel 2017-10-31 15:25 ` Heyi Guo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox