From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 E11BA1A1E59 for ; Thu, 8 Sep 2016 10:49:32 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id c198so94933273ith.1 for ; Thu, 08 Sep 2016 10:49:32 -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:content-transfer-encoding; bh=wovm6k1oB9nQ15+QAMYbOA5VfJN2vWhRpbyNZUkfPug=; b=Y+2Svk5tRdl/EJAbzKdONvrAUg4KPB0R7KGbpJ8mdmopcepzdT0KKK/T9iw25ZM2Wj vcnARdPrhz0KzX9T9qJlEoxTiJ7h864xAHyW8jaopeynjPOv5XmozCliTLXQj3l2Uafd w4hqoSyMTjFJDXEQbCHjmXEc4V333VYC381m4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wovm6k1oB9nQ15+QAMYbOA5VfJN2vWhRpbyNZUkfPug=; b=XSHNqbRGdXm78E6AvPAR6S86+4qjLvEuFDREF8zPsT+vuf4sKTRcJtNpc9hN/4MMOu poZZ+dRDW0PYQV1vzQgKTmU0DgJZNAhGZ8nQYfk74840Oe8Xp8lFUAV5fyGN6kf/FwT6 EIHCLZqQXHd9MhWa7rcc9sXHW1H7+MqGMGK6U+qqPORIxoRQXb5EMw/TVTHibaKBfrsO j+QAUqwneZprHHAA28qx/LTCc3vqdO1J84r+ZABszIAguqwpTnm2zF/wvRldCctDY969 CyQWnAqJ6WanV5D6ZwfZgc3YXQqjyRHmmCSW4lVFQIPthoIDL2aSMQr1Q/DmQa2q9WXu zSLw== X-Gm-Message-State: AE9vXwMBy3rWmxHz+nyoptX6u6ksK0g6UDcox2PsJPEOEriUYgE0+S8vreuCQCyV+t5tlpybJ+2Yby7c0+a5BDP3 X-Received: by 10.157.27.151 with SMTP id z23mr986418otd.72.1473356972007; Thu, 08 Sep 2016 10:49:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 8 Sep 2016 10:49:31 -0700 (PDT) In-Reply-To: References: <1473322418-9158-1-git-send-email-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 8 Sep 2016 18:49:31 +0100 Message-ID: To: "Cohen, Eugene" Cc: "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" Subject: Re: [PATCH] ArmPlatformPkg: remove EFI_MEMORY_UC attribute from normal memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 17:49:33 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 September 2016 at 18:33, Cohen, Eugene wrote: > Ard, > >> So remove the EFI_MEMORY_UC attribute that we set by default on >> system RAM. >> If any region requires this attribute, it is up to the driver to set thi= s >> attribute, and to ensure that no offending operations are performed >> on it. >> > > For DMA common-buffer operations on systems without snooping DMA capabili= ties, UC or WC mapping of system memory regions is required. > >> EFI_RESOURCE_ATTRIBUTE_PRESENT | >> EFI_RESOURCE_ATTRIBUTE_INITIALIZED | >> - EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE | >> EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE | >> EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE | >> EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE | > > The EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE bit your removing is removing the = capability for uncacheable memory such that even if a driver wanted to make= a DMA buffer uncacheable GCD will no longer allow this because the resourc= e does not support this capability. > > Is it your intent to indicate that system memory is no longer capable of = being uncacheable? If so how would you plan to accomodate the DMA use case= for GCD SetMemorySpaceAttributes? > In general, memory should be mapped as memory, and if strongly ordered mappings of RAM are required in some cases, it is up to the module itself to set the memory space capabilities, and to ensure that routines that expect normal memory are not used on them. The typical example is the proposed ARM implementation of BaseMemoryLibOptDxe, which uses unaligned accesses and DC ZVA operations to speed up operations. I checked ArmDmaLib, and it uses WC mappings for its uncached allocations, so those users should be fine. Do you have any examples of drivers that require device mappings of RAM for DMA? I think it would be preferable in this case to carve out a chunk of memory at the platform level instead of annotating all of RAM with the UC bit, given that it turns up in runtime services code/data regions as well, giving the OS license to map it using attributes that may be problematic.