From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 7DB1620D77DD1 for ; Wed, 5 Apr 2017 13:34:41 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id l7so17574616ioe.3 for ; Wed, 05 Apr 2017 13:34: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=9lVaQokpuEnSfA4sa7SEwcfmxPSzPbP+aBkw3MpDg88=; b=OSVMB6+vvzMI9FpnQfuaXV0Jj5Zizu2zY/6lCK2T3y4t5M75FXVtQBQsspg67nKaij GDdPvLnt9nG26PGfZQCQwK8boESVGHXT+1PcmXFN7Z0+4fove4EmApW+UFpg/yfexTFo zw2iPQ7rtp0sINzvSbKy+E5LHVsyblh5D5iJ0= 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=9lVaQokpuEnSfA4sa7SEwcfmxPSzPbP+aBkw3MpDg88=; b=iyj+N26OQObKgVvNsmyInhRcr1+kkJP0zfO8ZLWn2IY9X8UUFQTE3Nl4S8C9GdvFr2 4wj1Rb5Nybhz0j3A9Rr1/z/eO8za/JgTdJjBAIlcniAyl+1pqd2H2nh59MRZD/PAZ9Ev TeoAiO3IBP74dIenMxw6jMetez4bdvO5f8JbQYlYHBopOr7T/0qjmk1/zSXSCUg/26kx CP5MS8uPt8xSMuyInXgZKF1pWsv4QEP0x2zYHNxqxp5XdfPLecMY4RpvPb3i3hfFhZKf LG/qkDq3GoJMxNJPeJ0d9yPHr0urwY74w2A4UDmBONDQVwZskJVMaFdOYKbBcShhxquP yQkg== X-Gm-Message-State: AFeK/H1ghvFkHUVxHhmOwmF3J2g6A7bPlnNCB3x2bPvTVFpMYm65x1n4CZ+1DqOeJnO9P/VRwUQIAulOJoCcLmVf X-Received: by 10.107.168.21 with SMTP id r21mr27939514ioe.45.1491424480698; Wed, 05 Apr 2017 13:34:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Wed, 5 Apr 2017 13:34:40 -0700 (PDT) In-Reply-To: References: <1473429644-13480-1-git-send-email-ard.biesheuvel@linaro.org> <1473429644-13480-5-git-send-email-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Wed, 5 Apr 2017 21:34:40 +0100 Message-ID: To: Jeremy Linton , Leif Lindholm Cc: "edk2-devel@lists.01.org" , "Gao, Liming" , "Kinney, Michael D" Subject: Re: [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases 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: Wed, 05 Apr 2017 20:34:41 -0000 Content-Type: text/plain; charset=UTF-8 On 5 April 2017 at 21:12, Jeremy Linton wrote: > Hi, > > On 09/09/2016 09:00 AM, Ard Biesheuvel wrote: >> >> The new accelerated ARM and AARCH64 implementations take advantage of >> features that are only available when the MMU and Dcache are on. So >> restrict the use of this library to the DXE phase or later. > > > I don't think this is sufficient because DC ZVA doesn't work against device > memory/etc. That means that users have to somehow know the page/etc > attributes of memory regions before they call SetMemXX() on them. > Yes. I literally found this out myself yesterday. Note that this applies equally to unaligned accesses. > I think this is a problem because nowhere in the UEFI specs do I see such > restrictions on those memory operations. > Using device attributes for memory is something we should ban for AArch64 in the spec. > For a specific problematic example, the LcdGraphicsOutputBlt.c uses it for > BltVideoFill() and the target of that is likely not regular cached video > memory. > Those drivers should be using EFI_MEMORY_WC not EFI_MEMORY_UC for the VRAM mapping. Note that EFI_MEMORY_UC is nGnRnE which is unnecessarily restrictive. I agree there is a general issue here which we should address by tightening the spec. I don't see a lot of value in avoiding DC ZVA and unaligned accesses altogether, I'd rather fix the code instead. Thanks, Ard.