From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bounce+27952+118033+7686176+12367111@groups.io>
Received: from mail05.groups.io (mail05.groups.io [45.79.224.7])
by spool.mail.gandi.net (Postfix) with ESMTPS id 64BC97803D0
for <rebecca@openfw.io>; Fri, 19 Apr 2024 16:36:59 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; bh=RhhCtKVcHheFM7j8kdLYJjpfRKZU7xVszZ5b/hyb8EA=;
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=1713544618; v=1;
b=fL2tWdQONY0lyiDp4z9wnLZpOPv3jFpPC+y7vrPhk7WzoU3DVV7yrrAEu5xkAVS+uigITRFx
m+S/H/m5dVx+tfRDhPp0lJJOGLIlVXINslsd0Gg/I68ErPk1K08QYG0yNwrQWIWqHKRZ7doicJN
xA8tnwWtJ3iJjIxgjZM5An8PWZjb+7TX5jIeFinJXgRyllmo2iyGtyicBav1V+6+mr+7l+cOFs6
iNpXs0mG+CKkWtDVUTp6P+hOVZ28WwKbouWbVHNssNFDz30NJKd2fX97Oz3PorM72s1hsRdHzCf
aHSBL0gOH+S075rDiTcn3b9J15jTuoqg4AhY3hpW4gufw==
X-Received: by 127.0.0.2 with SMTP id krVqYY7687511xDpl7hTi84M; Fri, 19 Apr 2024 09:36:58 -0700
X-Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
by mx.groups.io with SMTP id smtpd.web10.26086.1713544617067458167
for <devel@edk2.groups.io>;
Fri, 19 Apr 2024 09:36:57 -0700
X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
by dfw.source.kernel.org (Postfix) with ESMTP id 86F2661A55
for <devel@edk2.groups.io>; Fri, 19 Apr 2024 16:36:56 +0000 (UTC)
X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11400C2BD10
for <devel@edk2.groups.io>; Fri, 19 Apr 2024 16:36:56 +0000 (UTC)
X-Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-516d264d0e4so3150507e87.0
for <devel@edk2.groups.io>; Fri, 19 Apr 2024 09:36:55 -0700 (PDT)
X-Gm-Message-State: nYljqSqifRyglFF0VAksaYwxx7686176AA=
X-Google-Smtp-Source: AGHT+IEXm9sbgybt/g7hFtY3tcnslbNK6rEr9BEf2v6EJyd9YvfCV7hYtaq6T1c4Fst1aViPDd2yoFQue38DOa3ziDY=
X-Received: by 2002:ac2:4651:0:b0:519:99c:9018 with SMTP id
s17-20020ac24651000000b00519099c9018mr816835lfo.11.1713544614093; Fri, 19 Apr
2024 09:36:54 -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> <kjpkyoux2xcegrqshde5ddhicf33jnlelobuzuo4uj4svvlzdn@rilun7dz6776>
<20240419170938.00000551@huawei.com>
In-Reply-To: <20240419170938.00000551@huawei.com>
From: "Ard Biesheuvel" <ardb@kernel.org>
Date: Fri, 19 Apr 2024 18:36:42 +0200
X-Gmail-Original-Message-ID: <CAMj1kXE+0mUfFq_FrhZT0m_YOJkWiuPndWt3GsRn1eMyCVrmMw@mail.gmail.com>
Message-ID: <CAMj1kXE+0mUfFq_FrhZT0m_YOJkWiuPndWt3GsRn1eMyCVrmMw@mail.gmail.com>
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 <kraxel@redhat.com>, Jonathan Cameron via <qemu-devel@nongnu.org>, linuxarm@huawei.com,
Richard Henderson <richard.henderson@linaro.org>, qemu-arm@nongnu.org,
=?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= <philmd@linaro.org>,
Idan Horowitz <idan.horowitz@gmail.com>
Precedence: Bulk
List-Subscribe: <mailto:devel+subscribe@edk2.groups.io>
List-Help: <mailto:devel+help@edk2.groups.io>
Sender: devel@edk2.groups.io
List-Id: <devel.edk2.groups.io>
Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io
Resent-Date: Fri, 19 Apr 2024 09:36:57 -0700
Resent-From: ardb@kernel.org
Reply-To: devel@edk2.groups.io,ardb@kernel.org
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/plugh>
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=fL2tWdQO;
dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none);
spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io
On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
<jonathan.cameron=huawei.com@groups.io> wrote:
>
> On Fri, 19 Apr 2024 13:52:07 +0200
> Gerd Hoffmann <kraxel@redhat.com> 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 <ardb@kernel.org>
> 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 <ardb@kernel.org>
> Acked-by: Laszlo Ersek <lersek@redhat.com>
> Tested-by: dann frazier <dann.frazier@canonical.com>
>
> 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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118033): https://edk2.groups.io/g/devel/message/118033
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]
-=-=-=-=-=-=-=-=-=-=-=-