From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c05::234; helo=mail-pg0-x234.google.com; envelope-from=heyi.guo@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 BC99A2034CF81 for ; Mon, 30 Oct 2017 08:09:54 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id l24so11859750pgu.11 for ; Mon, 30 Oct 2017 08:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ze+Xp8flOln3KatK5uz2MjoJyT2EiiYN84k/53QifT4=; b=bGjsSNVxbcElX1Pa5El7J1nxPZTVjKGqFsuNMjnOe4MKfAYxAcGtYxxP3z7cL4269J OSVXmdSwjxl0q8xExkuHvdXoAULVC2UaFtY2ailtBBarHmQWcAahjiv//e0FtXKTF4l6 msq1bsuioucrInnfY1nGG+7jks6WXKt/gLq+k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ze+Xp8flOln3KatK5uz2MjoJyT2EiiYN84k/53QifT4=; b=qDoNKriVWORgbPtqSFu+j+knf//xsY/gItq+s6zd84/bjqB2FkUhvv2GQRVePG50GD bEHqWHHc7nlqbfjeBdKYp/9u/U/y69aaUg+AEeSCAOWIvlCC+5ZqZ/VmKpYnEciXL2MZ avOKm9F+jGEx6xQQUFjIrBIo7oIt3jg/R8JcPwsqM2KOBH5bSZ2SOonnLpVMQvEn+VxV Bgxbf+SgCKE4Z3eZWxn8zl/RmJHRi04JNB73ekoFzIubHc0NgtsNcuDpw7NrlOiCBj+G ww1dOH8Jud7X+u/Lj8bbYCd2L39uZgnVSZbqmVQGYSc46S0N5kU2+ITJACClWFqkqAz2 Yk3A== X-Gm-Message-State: AMCzsaV8wWdnWbE/UTIkJGd0If/nuncKiVpSUWIc1Pz6jVx/9bW71zzA AaZ+cD5ogdc5037f+KhEgvjRuA== X-Google-Smtp-Source: ABhQp+SjJKuxBTdQ+Ji9EB7dgyT/gdcTGXaCQds2H4DOwwOkhoSu4Ek5qJR4TC1DIYddSvkOLFWQmA== X-Received: by 10.98.89.219 with SMTP id k88mr8990280pfj.229.1509376424936; Mon, 30 Oct 2017 08:13:44 -0700 (PDT) Received: from [10.110.137.118] ([89.47.15.17]) by smtp.gmail.com with ESMTPSA id h186sm25135633pfe.66.2017.10.30.08.13.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 08:13:44 -0700 (PDT) To: Ard Biesheuvel References: Cc: "edk2-devel@lists.01.org" , Linaro UEFI Mailman List , Leif Lindholm , "Ni, Ruiyu" From: Heyi Guo Message-ID: Date: Mon, 30 Oct 2017 23:13:39 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: 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:09:54 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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? 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. >