From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 67388D80520 for ; Fri, 19 Apr 2024 17:38:43 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=0EWrDJeuZlUh92tfKLPiB6R1XBtQNVU7PlCS26WT57Q=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240206; t=1713548321; v=1; b=QH0yprDJvOvI+mXrPOlTTKCrV5Hx/BK71/rcnXGeY1vv5UctR29ZFh3/c3/K5spl7rNSXGVx bDZO5suGzsGtXXGrlOafzp43HX5FMKLc1Ky5+PqXG/QfcRHBvK0Y6yQirGYr7FvCcoz8F1jepqz Vz2Wsz+bVBNqrsy1jtlnyqLTuVo0sAXhZF9OwqCM8o1kBMKaBJTF1xfwfMg/GVh2sRt4V79KpGp O2qhwpMUTpjPkXfObNdVzToFM2odmx1R3fC1dZcNaBSeMX8/a41KihcWT7sMZzwPwxQWbdzbkgP W9GL8pn7ZEdB1KqjC655XAW7kwi1tP0oLI3kKNgWM34BA== X-Received: by 127.0.0.2 with SMTP id 5nUmYY7687511x6jXXJh6aZc; Fri, 19 Apr 2024 10:38:41 -0700 X-Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.89.1713548321082656590 for ; Fri, 19 Apr 2024 10:38:41 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 755C0619E1 for ; Fri, 19 Apr 2024 17:38:40 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5D4FC3277B for ; Fri, 19 Apr 2024 17:38:39 +0000 (UTC) X-Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2d8863d8a6eso34824701fa.3 for ; Fri, 19 Apr 2024 10:38:39 -0700 (PDT) X-Gm-Message-State: Jax0TvTeA8LJG9rcPYCjE1FQx7686176AA= X-Google-Smtp-Source: AGHT+IFi5z5fnH8BG2u+jRYH1xTrUkI8887vezK/4uwcjOxEWZjSnalD1oK952RGvlZ7fU8YtTRGHWmyw4kk0qiFreA= X-Received: by 2002:a05:6512:159:b0:518:b283:1078 with SMTP id m25-20020a056512015900b00518b2831078mr2445253lfo.26.1713548318060; Fri, 19 Apr 2024 10:38:38 -0700 (PDT) MIME-Version: 1.0 References: <20240301204110.656742-1-richard.henderson@linaro.org> <20240301204110.656742-6-richard.henderson@linaro.org> <20240416161111.0000607c@huawei.com> <0c878d25-3fbb-4f0b-bc9e-ca638f8c4f1e@linaro.org> <20240418091555.00006666@Huawei.com> <20240418183600.00000345@huawei.com> <20240419170938.00000551@huawei.com> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 19 Apr 2024 19:38:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled To: devel@edk2.groups.io, jonathan.cameron@huawei.com Cc: Gerd Hoffmann , Jonathan Cameron via , linuxarm@huawei.com, Richard Henderson , qemu-arm@nongnu.org, =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Idan Horowitz Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Fri, 19 Apr 2024 10:38:41 -0700 Resent-From: ardb@kernel.org Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=QH0yprDJ; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) On Fri, 19 Apr 2024 at 18:36, Ard Biesheuvel wrote: > > On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io > wrote: > > > > On Fri, 19 Apr 2024 13:52:07 +0200 > > Gerd Hoffmann wrote: > > > > > Hi, > > > > > > > Gerd, any ideas? Maybe I needs something subtly different in my > > > > edk2 build? I've not looked at this bit of the qemu infrastructure > > > > before - is there a document on how that image is built? > > > > > > There is roms/Makefile for that. > > > > > > make -C roms help > > > make -C roms efi > > > > > > So easiest would be to just update the edk2 submodule to what you > > > need, then rebuild. > > > > > > The build is handled by the roms/edk2-build.py script, > > > with the build configuration being in roms/edk2-build.config. > > > That is usable outside the qemu source tree too, i.e. like this: > > > > > > python3 /path/to/qemu.git/roms/edk2-build.py \ > > > --config /path/to/qemu.git/roms/edk2-build.config \ > > > --core /path/to/edk2.git \ > > > --match armvirt \ > > > --silent --no-logs > > > > > > That'll try to place the images build in "../pc-bios", so maybe better > > > work with a copy of the config file where you adjust this. > > > > > > HTH, > > > Gerd > > > > > > > Thanks Gerd! > > > > So the builds are very similar via the two method... > > However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE > > > > And that's the difference - with that set for my other builds the alignment > > problems go away... > > > > Any idea why we have that set in roms/edk2-build.config? > > Superficially it seems rather unlikely anyone cares about thunderx1 > > (if they do we need to get them some new hardware with fresh bugs) > > bugs now and this config file was only added last year. > > > > > > However, the last comment in Ard's commit message below seems > > highly likely to be relevant! > > > > Chasing through Ard's patch it has the side effect of dropping > > an override of a requirement for strict alignment. > > So with out the errata > > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only > > is replaced with > > [BuildOptions] > > +!if $(CAVIUM_ERRATUM_27456) == TRUE^M > > + GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M > > +!else^M > > GCC:*_*_AARCH64_CC_XIPFLAGS == > > +!endif^M > > > > The edk2 commit that added this was the following +CC Ard. > > > > Given I wasn't sure of the syntax of that file I set it > > manually to the original value and indeed it works. > > > > > > commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41 > > Author: Ard Biesheuvel > > Date: Wed Jan 4 16:51:35 2023 +0100 > > > > ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX > > > > The early ID map used by ArmVirtQemu uses ASID scoped non-global > > mappings, as this allows us to switch to the permanent ID map seamlessly > > without the need for explicit TLB maintenance. > > > > However, this triggers a known erratum on ThunderX, which does not > > tolerate non-global mappings that are executable at EL1, as this appears > > to result in I-cache corruption. (Linux disables the KPTI based Meltdown > > mitigation on ThunderX for the same reason) > > > > So work around this, by detecting the CPU implementor and part number, > > and proceeding without the early ID map if a ThunderX CPU is detected. > > > > Note that this requires the C code to be built with strict alignment > > again, as we may end up executing it with the MMU and caches off. > > > > Signed-off-by: Ard Biesheuvel > > Acked-by: Laszlo Ersek > > Tested-by: dann frazier > > > > Test case is > > qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \ > > -bios QEMU_EFI.fd -d int > > > > Which gets alignment faults since: > > https://lore.kernel.org/all/20240301204110.656742-6-richard.henderson@linaro.org/ > > > > So my feeling here is EDK2 should either have yet another config for QEMU as a host > > or should always set the alignment without needing to pick the CAVIUM 27456 errata > > which I suspect will get dropped soonish anyway if anyone ever cleans up > > old errata. > > > > This code was never really intended for execution at EL2, but it > happened to work, partially because TCG's lack of strict alignment > checking when the MMU is off. > > Those assumptions no longer hold, so yes, let's get this fixed properly. > > Given VHE and nested virt (which will likely imply VHE in practice), I > would like to extend this functionality (i.e., the use of preliminary > page tables in NOR flash) to EL2 as well, but with VHE enabled. This > means we can still elide TLB maintenance (and BBM checks) by using > different ASIDs, and otherwise, fall back to entering with the MMU off > if VHE is not available. In that case, we should enforce strict > alignment too, so that needs to be fixed regardless. > > I'll try to code something up and send it round. In the mean time, > feel free to propose a minimal patch that reinstates the strict > alignment if you are pressed for time, and I'll merge it right away. Actually, let's just so that first - I'll send out a patch. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118036): https://edk2.groups.io/g/devel/message/118036 Mute This Topic: https://groups.io/mt/105602816/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-