From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400c:c05::236; helo=mail-vk0-x236.google.com; envelope-from=heyi.guo@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 E19282035D0F9 for ; Tue, 31 Oct 2017 08:22:08 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id t184so10599326vka.6 for ; Tue, 31 Oct 2017 08:26:00 -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=+B/LRKp4w/2oCeBmY+XzS2dMbVPwHBqQx60j8JGxf/A=; b=di0HGvOX6EQlGZxKjPSaB8R+5Eyt4FtjmCzxkMvhLv/AyD/dS6a67lLUWjzN+5Os1P o8wxjgOtcTeYsCy+ZSSZ4UU/5zIdeXee844NzmebCKhQEYEtWzw9NdPTmTKukNrChi8O 1STi39T+ah90OxnKPNNWSkT1hZ1JAEPFcEVwk= 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=+B/LRKp4w/2oCeBmY+XzS2dMbVPwHBqQx60j8JGxf/A=; b=fXzDdGYSGVOw4a74951YyodB3x6QBOXvVE6WQ39qXyO+ptJLVVDu+wmNNY4ZR9XMtT XAYLTkyTChZkZUi6l1iqWgov5iGcWNumYqxbFbtOeTI03/F1YqYOgAZ0Uu3nFY0yG+x6 7mOoTuyYutiROm6G5732KKjC3YFRhA1ES4Zrc4oivJ7l6rM6ty2z1Zn/yHzN/cddSTPK L9HvkV1EihcPLT/nfQCV0j8b1kVo0OhxFYJCnUGDzproa3ZG3QvJiB/lwBzGJR40t8tn UTLweQ99FiATdZkh4eEv1CJFIKAi2US/5LNlJ2FTSQhyioKkUAmllleqo+ltM6mkWnJ9 KBXQ== X-Gm-Message-State: AMCzsaU4atfjH054z8mlUP//a9i091n9vwueftMFtigiv7p1unGEOeQo uinECHEx92GP/80ka7R8QIdidGtrUlvfzhJFKmJBkg== X-Google-Smtp-Source: ABhQp+SGgBk3LYfiPbnMK9xmohnE8ynQvt75aH5n4sDkvByv08+t3mFAy/7SZMhC1HDAuDHzWePQNrT8WT9ZXHd3/FY= X-Received: by 10.31.168.66 with SMTP id r63mr1593854vke.32.1509463559679; Tue, 31 Oct 2017 08:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.214.135 with HTTP; Tue, 31 Oct 2017 08:25:59 -0700 (PDT) In-Reply-To: References: From: Heyi Guo Date: Tue, 31 Oct 2017 23:25:59 +0800 Message-ID: To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Linaro UEFI Mailman List , Leif Lindholm , "Ni, Ruiyu" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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: Tue, 31 Oct 2017 15:22:09 -0000 Content-Type: text/plain; charset="UTF-8" OK, we'll make the change for D0x too. Thanks, Heyi On 30 October 2017 at 23:17, Ard Biesheuvel wrote: > 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. >