From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::243; helo=mail-io0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BDFC220352610 for ; Mon, 30 Oct 2017 08:14:02 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id p186so27911403ioe.12 for ; Mon, 30 Oct 2017 08:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0d8Bkwt3F1MwHpg5q73GqtSQqkNB6H/psqDvejgIfvI=; b=Xg63bcAqXDpQEFNCpL9kfxztEoHR5NZ0qOMMQwIpQTY3W2s12fYIvtq3dEotFaVLNd 1As27wDCwRNkMsmpEOvJrMFFnKg4BTqeORst+2/EhNN9r+8v02cLad8rahMXwsyvStHV fvYwBWX6jVzbXYzWCbLlmv6ogNWHeZA2CWwcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0d8Bkwt3F1MwHpg5q73GqtSQqkNB6H/psqDvejgIfvI=; b=JxE9UBgEXkajIWgfkdcWEQ8FMXgNTXxpTUc6mOuz56NhJqssIQ3jF0H5Cmhwq+JeAv V0fCUI4Mev+Dj9bHPZC7ax1wOO+nY1Tuk2L8Bw1Rzb8TNhBHGiqKj5bLl060hbO3XLt4 h8AYpkk5y7oEdfFZlfVT5ogWPjYRryjJ3F27XzwBqV5ItVvwgv7RGle+dTxaq/SR15IP iy1aEX1tFjf5L1qGqtw4rQ3C70IHXk7j36w97yPj/8XlaVTv9iWkurpqiuZElSpB4l4u M5Uc8ria9dm/T8X9JgxK5jagX8wODtXWWpM6z3wjCl4lTT4ExVpsAxxvEYHLW6THWzzj ofZA== X-Gm-Message-State: AMCzsaU6VCnfAG35WKAuK5DkkgN1qHr5ywoGEPjTMfGLtHFQ9JbOG8/i n2FgWmvy/2R7aVt5l112VHb/kA8PAjmrNPx5GX90k11X X-Google-Smtp-Source: ABhQp+TZck4K3ocF/JaEqFB/fto6cMt9fWNih4sxOsmPiC9vjzc5d7hd4odhMhKVoPAVoenlGSCpshK22IoJv6VLKa0= X-Received: by 10.107.151.19 with SMTP id z19mr11643114iod.248.1509376672703; Mon, 30 Oct 2017 08:17:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Mon, 30 Oct 2017 08:17:45 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Mon, 30 Oct 2017 15:17:45 +0000 Message-ID: To: Heyi Guo Cc: "edk2-devel@lists.01.org" , Linaro UEFI Mailman List , Leif Lindholm , "Ni, Ruiyu" Subject: Re: [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:14:03 -0000 Content-Type: text/plain; charset="UTF-8" On 30 October 2017 at 15:13, Heyi Guo wrote: > Hi Ard, > > > On 10/30/2017 04:21 PM, Ard Biesheuvel wrote: >> >> On 30 October 2017 at 03:52, Heyi Guo 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.