All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: devel@edk2.groups.io,
	"Jonathan Cameron via" <qemu-devel@nongnu.org>,
	linuxarm@huawei.com,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-arm@nongnu.org, "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Idan Horowitz" <idan.horowitz@gmail.com>,
	"Ard Biesheuvel" <ardb@kernel.org>
Subject: Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled
Date: Fri, 19 Apr 2024 17:09:38 +0100	[thread overview]
Message-ID: <20240419170938.00000551@huawei.com> (raw)
In-Reply-To: <kjpkyoux2xcegrqshde5ddhicf33jnlelobuzuo4uj4svvlzdn@rilun7dz6776>

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.

Jonathan





  reply	other threads:[~2024-04-19 16:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 20:41 [PATCH v3 0/6] target/arm: Do memory alignment check for device memory Richard Henderson
2024-03-01 20:41 ` [PATCH v3 1/6] target/arm: Support 32-byte alignment in pow2_align Richard Henderson
2024-03-01 20:41 ` [PATCH v3 2/6] exec/memattrs: Remove target_tlb_bit* Richard Henderson
2024-03-01 20:41 ` [PATCH v3 3/6] accel/tcg: Add tlb_fill_flags to CPUTLBEntryFull Richard Henderson
2024-03-01 20:41 ` [PATCH v3 4/6] accel/tcg: Add TLB_CHECK_ALIGNED Richard Henderson
2024-03-01 20:41 ` [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled Richard Henderson
2024-04-16 15:11   ` Jonathan Cameron via
2024-04-17 20:07     ` Richard Henderson
2024-04-18  8:15       ` Jonathan Cameron via
2024-04-18 17:40         ` Jonathan Cameron via
2024-04-19 11:52           ` [edk2-devel] " Gerd Hoffmann
2024-04-19 16:09             ` Jonathan Cameron via [this message]
2024-04-19 16:36               ` Ard Biesheuvel
2024-04-19 17:38                 ` Ard Biesheuvel
2024-04-22 15:26   ` Clément Chigot
2024-04-22 15:47     ` Richard Henderson
2024-04-22 15:59       ` Peter Maydell
2024-03-01 20:41 ` [PATCH v3 6/6] target/arm: Do memory type alignment check when translation enabled Richard Henderson
2024-03-04 17:10   ` Peter Maydell
2024-03-04 17:27     ` Richard Henderson
2024-03-04 17:12 ` [PATCH v3 0/6] target/arm: Do memory alignment check for device memory Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240419170938.00000551@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=ardb@kernel.org \
    --cc=devel@edk2.groups.io \
    --cc=idan.horowitz@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=linuxarm@huawei.com \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.