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::22a; helo=mail-io0-x22a.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 086602034CF7F for ; Mon, 30 Oct 2017 01:17:50 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 97so25271287iok.7 for ; Mon, 30 Oct 2017 01:21:41 -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=5FWbzgIJw+MxSKOaDOmy/tWdmjxQEHJjnZHITi2vPKI=; b=I9kQdIX5euYxKsFma0uXmgJA+857aqmb7iTKNohC/9kd6pA+OTJocO69nezrHcnD65 8nrtov8rUfCEp1C46Qa7TYLHCqPBeBrzIqwGPNmHJJYc6BEP7ijQ0fAGM4WCrIbKDdow LvedrjncQNR9zpSnUTUxi24S+E+IWGZAkirVg= 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=5FWbzgIJw+MxSKOaDOmy/tWdmjxQEHJjnZHITi2vPKI=; b=nyw12xLdW0dNRp77T6PNxPMd4PzmicEq74xDguCVkMNfVkjSBtAn0bYEnVzWNqEx/i j1uqnrR8Na4x5GP6CTcAyzHCR6KMxLTh6F87o3DVjw/5hcVwV+jKPgAgsKj0plBTyB14 sTYE0GudAIAaR/45gdlKLUO9sefh6T10noBZOhwXcR4FGsNfX/mnLRFjuSBUkw061gmT WHwROiI0nAnb1cqHqiBZVv7KKKTdS/pqDrX5X3F02h4EtU0z3JUTfQkpAC14SDoubpDs Cq8zzOndmk1FjwCdyiJ7EaAzz8G7lVMP53BW0QeyQsC7x0MIOyeK8U0kuUBuDGFvrU77 bQOg== X-Gm-Message-State: AMCzsaU/pDuS1at9XTCVOnuOub5DJN+YP1s2Amke8opZjCwiUXejpf+N /+OGiTVqDgmlM1oLEASkdSQVHKf694N90xijG80IEKXc X-Google-Smtp-Source: ABhQp+RL/GFGZe6hEltblFQkXpoG61V8aIbB6gtXyXATQL22Vkjrq1CS4gr8sk+Misp6P+GSZ5JzIA0biQpOwk4V3mw= X-Received: by 10.36.210.198 with SMTP id z189mr4943034itf.65.1509351700615; Mon, 30 Oct 2017 01:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Mon, 30 Oct 2017 01:21:40 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Mon, 30 Oct 2017 08:21:40 +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 08:17:51 -0000 Content-Type: text/plain; charset="UTF-8" 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. 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.