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 D1D3C20355209 for ; Wed, 15 Nov 2017 05:58:53 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id m191so1846057itg.2 for ; Wed, 15 Nov 2017 06:03:02 -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=taYUIVLARbTXKjmpTH7KGbWlLnJdWqFdUgykgXzZXUs=; b=Mho1m39eJdygUkJlyN7G7Qyxv+5o8KHU7+1Uqy9U362qkQb9E8u314/gjRDRGmmd7l 0Fw8oldZDZoOxBIPp8H9doZrhDrLr14NX1BRWhzLd5/5VatMyLpjFN7NpsEjQYvnMOhr oxPFc18bW/A+wMRykIzeGZixTB9shyKNqXyhk= 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=taYUIVLARbTXKjmpTH7KGbWlLnJdWqFdUgykgXzZXUs=; b=ZIZtJiUNcu2KsxDcHt0SLrXZUXzpI5960tMrXDnhwlReEN9MWhVhAS7OOI3qGZ8Qvm mwVV6Yhl3Ke3GLBYpLGHZ1NNtcmbuDP1Ib27x+xRpXXHhfC5wA8rrDUJvIsfQA8C9V4c pK6RjoIZM0gTA/qmCuu0Tn6+rSf9z/vX3EcOflv6GeZU07fC/GhvCCFszmNJmMINKHhP U+lhNiVFPX6+OO8Zt5BSoPOufyevSicE6Q+H0U3C58MyiqDAmQyDRkmJTgv0wDpxSF61 JGvwBHdU3mlqOTmNxEaJs5xMlQKNDt9JS+FOnSeWgNym4if/GhOFHp7yisF7QktEyPYC f61A== X-Gm-Message-State: AJaThX4jwJ0nCF9D6GSDGocLZloFb9eUic5L5ECMRsptMlrzHxuSZ04H X8XEaD1cPQ950Xr4woPM3LWhiV4h2xgg9s3L9/4ghA== X-Google-Smtp-Source: AGs4zMZz65bT0QdVSMUn8xsdNWxz8Jw9rVrLdc4GrA6DVqLBBfOhX4SJ50HeMA+sK0X6eYuSXopysV8OIcZKA/BrW9U= X-Received: by 10.36.141.70 with SMTP id w67mr19554099itd.58.1510754581599; Wed, 15 Nov 2017 06:03:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.20 with HTTP; Wed, 15 Nov 2017 06:03:01 -0800 (PST) In-Reply-To: References: <20171114102205.30649-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Wed, 15 Nov 2017 14:03:01 +0000 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Shannon Zhao 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: Wed, 15 Nov 2017 13:58:54 -0000 Content-Type: text/plain; charset="UTF-8" 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.