public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: Michael Kubacki <mikuback@linux.microsoft.com>,
	Sean Brogan <sean.brogan@microsoft.com>,
	 Gerd Hoffmann <kraxel@redhat.com>,
	Michael Kinney <michael.d.kinney@intel.com>,
	 edk2-devel-groups-io <devel@edk2.groups.io>,
	Jiewen Yao <jiewen.yao@intel.com>,
	 Oliver Steffen <osteffen@redhat.com>
Subject: arm64 support for stuart
Date: Wed, 25 Jan 2023 15:32:56 +0100	[thread overview]
Message-ID: <CAMj1kXGrha7Vy7Q7EEPqsox7YxuVug2g_wvhOmAVx1wNkQvMYg@mail.gmail.com> (raw)

Hello all,

Given some recent issues with OVMF and ArmVirtPkg, where regressions
were not caught, or resulted in different behavior between TCG
(emulation) and KVM (virtualized executon) when running under KVM.

So I have started with increasing the test coverage for ArmVIrtPkg,
even for configurations that are not necessarily used in production.
(E.g., ArmVirtQemu can be built with secure boot support, even though
the virtual platform is not constructed in a way where using it makes
a lot of sense). This should increase the likelihood that we will
catch CryptoPkg or SecurityPkg build time regressions that could
potentially affect other ARM platforms as well.

Another thing I would like to implement is support for running QEMU in
KVM mode from stuart_build.py. One aspect of that is deciding whether
or not KVM is available and accessible (suggestions welcome,
especially with the containerized build env now in the mix)

On arm64, the architecture is much more finicky when it comes to
memory ordering, alignment and mismatched memory attributes and
coherency, and so enabling boot testing under KVM would be a
meaningful addition there as well, given that TCG emulation does not
model any of these behaviors However, the stuart stack fails to locate
some of its dependencies (notably mu_nasm and iasl), and so I cannot
even build the firmware on a arm64 Linux system, let alone execute it
under virtualization.

Given that nasm is x86 specific, we should be able to work around this
by moving the nasm_ext_dep.yaml file into the right place. Then,
if/when mu_nasm for arm64 becomes available, we will also be able to
build OVMF from arm64 (although I am probably the only person in the
world who does that regularly.)

iasl is a different matter, as we need it to build for arm64 as well.
iasl is already available in the arm64 distros, so as I see it, there
are 3 options here:
- build iasl for Linux/arm64 and add it to the nuget repo
- allow a fallback to system-wide iasl (how?)
- install the x86 version and run it under qemu user mode emulation
(which can be enabled transparently on most distros using binfmt-misc)

I have no idea whether or not the latter is feasible in terms of
dependencies (i.e., if the binaries are statically built, it should be
straightforward, but otherwise it is going to be tricky)

With this out of the way, I can happily run stuart_setup/update/build
and build and boot test ArmVirtQemu under KVM virtualization.

             reply	other threads:[~2023-01-25 14:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 14:32 Ard Biesheuvel [this message]
2023-01-25 16:55 ` arm64 support for stuart Gerd Hoffmann
2023-01-25 17:52   ` [edk2-devel] " Michael Brown
2023-01-25 18:04   ` Oliver Steffen
2023-01-25 18:27   ` Oliver Steffen
2023-01-25 19:00     ` [edk2-devel] " Michael D Kinney
2023-01-25 20:21       ` Oliver Steffen

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-list 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=CAMj1kXGrha7Vy7Q7EEPqsox7YxuVug2g_wvhOmAVx1wNkQvMYg@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox