From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.161929.1673857137464950975 for ; Mon, 16 Jan 2023 00:18:57 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WxjfWMFQ; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 96C1A60ED8 for ; Mon, 16 Jan 2023 08:18:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05C11C43396 for ; Mon, 16 Jan 2023 08:18:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673857136; bh=lA92qIJKYivRSgD0lPzalw7PRaYcCh4vvAEf9sLp7GM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WxjfWMFQaWBhscReHMoProB5B7rt0vRzMitSv0YX2ES6Rhu79YfxGvQ17mVLcXPBN KVwXk4lEfzFnp9aJzkEviaCblh19Y4VK8FjtFtOOPsut3II2xX+vb+Kr+P+P1zLqV9 37pqfFB+oPiqPRy04aUr7YafXO8MkKAN20c/GiNwJ5HuBWDz18jlBsonXsEnjC2ic5 x5ZdA5L0yJlYvr4o/hSeo+X0fk7w/VqKDi7yggPXdvd+1OSAbl3J3RjPZSe8jBgFcl wzWjH26qF+GfawrXvDIBdk2lOE7yupokSnzIaZ6P7XwVS794FrFiJbbjyWPEcXC0iJ 2q5LlMi3Saa5g== Received: by mail-lj1-f181.google.com with SMTP id e16so2334280ljn.3 for ; Mon, 16 Jan 2023 00:18:55 -0800 (PST) X-Gm-Message-State: AFqh2krVgWPqv2R15cSSgKdLl2w+N/q9tmTLjFRI4xU5fExWiOx4qIzK ibYjbH6sJxER79hGv3oRmhc6Mm75C2yxNsB0l30= X-Google-Smtp-Source: AMrXdXviH9SYFH9Smfwwlo4ihGHFcdfC06CE3mspeyLfGMDwvVnLLGiTe7Npj0WzBkoBxfpcZSVLNOa+Zq4AweSU9S8= X-Received: by 2002:a05:651c:238e:b0:28b:814d:7087 with SMTP id bk14-20020a05651c238e00b0028b814d7087mr330075ljb.516.1673857133966; Mon, 16 Jan 2023 00:18:53 -0800 (PST) MIME-Version: 1.0 References: <20230111180023.3841167-1-kraxel@redhat.com> <20230116063809.4sgnz4th6m2dldrk@sirius.home.kraxel.org> In-Reply-To: <20230116063809.4sgnz4th6m2dldrk@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Mon, 16 Jan 2023 09:18:41 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/1] OvmfPkg/VirtNorFlashDxe: map flash memory as uncacheable To: Gerd Hoffmann Cc: devel@edk2.groups.io, Ard Biesheuvel , Jiewen Yao , Oliver Steffen , Jordan Justen , Pawel Polawski Content-Type: text/plain; charset="UTF-8" On Mon, 16 Jan 2023 at 07:38, Gerd Hoffmann wrote: > > On Thu, Jan 12, 2023 at 11:20:00AM +0100, Ard Biesheuvel wrote: > > On Wed, 11 Jan 2023 at 19:00, Gerd Hoffmann wrote: > > > > > > Switching from the ArmPlatformPkg/NorFlashDxe driver to the > > > OvmfPkg/VirtNorFlashDxe driver had the side effect that flash address > > > space got registered as EFI_MEMORY_WC instead of EFI_MEMORY_UC. > > > > > > That confuses the linux kernel's numa code, seems this makes kernel > > > consider the flash being node memory. "lsmem" changes from ... > > > > > > RANGE SIZE STATE REMOVABLE BLOCK > > > 0x0000000040000000-0x000000013fffffff 4G online yes 8-39 > > > > > > ... to ... > > > > > > RANGE SIZE STATE REMOVABLE BLOCK > > > 0x0000000000000000-0x0000000007ffffff 128M online yes 0 > > > 0x0000000040000000-0x000000013fffffff 4G online yes 8-39 > > > > > > ... and in the kernel log got new error lines: > > > > > > NUMA: Warning: invalid memblk node 512 [mem 0x0000000004000000-0x0000000007ffffff] > > > NUMA: Faking a node at [mem 0x0000000004000000-0x000000013fffffff] > > > > > > Changing the attributes back to EFI_MEMORY_UC fixes this. > > > > > > Fixes: b92298af8218 ("ArmVirtPkg/ArmVirtQemu: migrate to OVMF's VirtNorFlashDxe") > > > Signed-off-by: Gerd Hoffmann > > > > Reviewed-by: Ard Biesheuvel > > Laszlo pointed me to commit 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use > EFI_MEMORY_WC and drop AlignedCopyMem()") and I'm wondering whenever we > need to also bring back AlignedCopyMem, or is it safe to use CopyMem > because we know we operate on virtual hardware? > Ugh, thanks for spotting that. So there is one occurrence of CopyMem() that may operate on a device region with a misaligned address, and this is the one in NorFlashRead(). This call is made while the flash is in array mode, and so the device region is backed by a KVM memslot at that point, and a misaligned load or store will trigger a fault. We already swap out the optimized BaseMemoryLib for the generic one when building VariableRuntimeDxe, and so the best course of action here is probably to do the same for NorFlashDxe, rather than bringing back AlignedCopyMem.