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:c0b::243; helo=mail-it0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 8AF44220D4BF1 for ; Thu, 16 Nov 2017 01:35:28 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id x28so5156192ita.0 for ; Thu, 16 Nov 2017 01:39:37 -0800 (PST) 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=9aqUnV/330G+S4pGv9g4ShiVWf7qPxep69srCA5SWKA=; b=KkynAQiZZc1zUCstfh4KDXNL6m9kaImO3m4j7U6s9EN+3sdSNe1dIGlmqw72Upt0yD vQJJ/sGRgDnhTW+tnx2eMelQhhrnlbt+1+9zNssgyG41E/6Ol/hV1YGUAJWyjkDDXG9U pIYhyw6rKFoDlWWOkHzsnhp0anQWG7w/H4tfw= 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=9aqUnV/330G+S4pGv9g4ShiVWf7qPxep69srCA5SWKA=; b=FaoVbin0xbbrjk86ANa/i+LqK5XSi0UIpTN5TdnC0idkpErnZBkmYrgvhuOLoxf2b4 WOLDLz1R59PTZD/goWVWCtVCUpJ/uunCT11G8I8KZVBqlmBc2hy+Y/h2pXPF/onUGZ87 QjFXm397HrG/xtYYv6S2m+nGJSi0u52//wBZMnHlfub0ZlT9zFhFqMVJq8EbnuOE6Fw0 /iuovfHFvl4xdoapgu7lXvBVM/38Pcn2XA+BvFxeNyGc8UFXXhyO/swqZkp8iT9xNl4u tRIwwd0Tyo0L8mX9XqzhDeg3vu8NCwYWshKd0kuXtSRhBr71KoFnazkcktz3SwYDoP5U C8+w== X-Gm-Message-State: AJaThX6dKePfGMcdTrWs+pNKq+gtzVyiDZnlnHNLB0874ZF7ePdls6vH ebGqbTTUos2TgvQ0C/SeRU4pfPkr7mVwgKAjtawi9A== X-Google-Smtp-Source: AGs4zMa00jtUyze4bTwbOVJY/xn5/aIefPiKNIAqVmeC1umOfxKvgX14/fzwOGUPA0bQA4pFlqLxENQrvAcswR2GJPI= X-Received: by 10.36.145.203 with SMTP id i194mr1545039ite.73.1510825177087; Thu, 16 Nov 2017 01:39:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.3 with HTTP; Thu, 16 Nov 2017 01:39:36 -0800 (PST) In-Reply-To: <5A0CE34E.1050008@huawei.com> References: <20171114102205.30649-1-ard.biesheuvel@linaro.org> <5A0CE34E.1050008@huawei.com> From: Ard Biesheuvel Date: Thu, 16 Nov 2017 09:39:36 +0000 Message-ID: To: Shannon Zhao Cc: Laszlo Ersek , "edk2-devel@lists.01.org" Subject: Re: [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe 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: Thu, 16 Nov 2017 09:35:28 -0000 Content-Type: text/plain; charset="UTF-8" On 16 November 2017 at 01:01, Shannon Zhao wrote: > > > On 2017/11/15 22:03, Ard Biesheuvel wrote: >> On 15 November 2017 at 13:51, Laszlo Ersek wrote: >>> > On 11/14/17 11:22, Ard Biesheuvel wrote: >>>> >> The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions, >>>> >> assuming such regions always have full memory semantics. Given that >>>> >> those regions cannot be mapped as ordinary memory on ARM (due to the >>>> >> fact that the NOR flash requires device semantics while in write mode) >>>> >> this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe, >>>> >> since it may use unaligned accesses and/or DC ZVA instructions, both >>>> >> of which are incompatible with mappings using device semantics. >>>> >> >>>> >> Note that there is no way we can work around this by changing the >>>> >> mapping type between 'memory' and 'device' when switching from read to >>>> >> write mode and back, because the runtime mapping is created by the OS, >>>> >> and cannot be changed at will. >>>> >> >>>> >> So let's just switch to the unaccelerated version of BaseMemoryLib which >>>> >> does not have the same problem. >>>> >> >>>> >> Contributed-under: TianoCore Contribution Agreement 1.1 >>>> >> Signed-off-by: Ard Biesheuvel >>>> >> --- >>>> >> ArmVirtPkg/ArmVirtQemu.dsc | 2 ++ >>>> >> ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++ >>>> >> 2 files changed, 4 insertions(+) >>>> >> >>>> >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc >>>> >> index 8a60b61f2aa6..7b220d6e3c31 100644 >>>> >> --- a/ArmVirtPkg/ArmVirtQemu.dsc >>>> >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc >>>> >> @@ -261,6 +261,8 @@ [Components.common] >>>> >> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf { >>>> >> >>>> >> NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf >>>> >> + # don't use unaligned CopyMem () on the UEFI varstore NOR flash region >>>> >> + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf >>>> >> } >>>> >> !if $(SECURE_BOOT_ENABLE) == TRUE >>>> >> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf { >>>> >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc >>>> >> index 9a31ec93ca06..7c032e1b07e0 100644 >>>> >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc >>>> >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc >>>> >> @@ -252,6 +252,8 @@ [Components.common] >>>> >> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf { >>>> >> >>>> >> NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf >>>> >> + # don't use unaligned CopyMem () on the UEFI varstore NOR flash region >>>> >> + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf >>>> >> } >>>> >> !if $(SECURE_BOOT_ENABLE) == TRUE >>>> >> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf { >>>> >> >>> > >>> > Reviewed-by: Laszlo Ersek >>> > >>> > Given that we've never seen the symptom reported by Shannon, I must >>> > think Shannon is using some kind of new hardware. May I ask what >>> > hardware that is? >>> > >> I think this is equally likely to occur in any KVM hardware >> virtualization context. It is simply a regression after moving to the >> OptDxe BaseMemoryLib flavor. > > Exactly. I'm using Huawei D05. It works well when I use a older edk2 > while fails when updating to UDK2017 branch. > > Tested-by: Shannon Zhao > Pushed as 44d71c217ccb Thanks.