Message ID | 20230530160924.82158-1-nikos.nikoleris@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | EFI and ACPI support for arm64 | expand |
On Tue, May 30, 2023 at 05:08:52PM +0100, Nikos Nikoleris wrote: > Hello, > > This series adds initial support for building arm64 tests as EFI > apps and running them under QEMU. Much like x86_64, we import external > dependencies from gnu-efi and adapt them to work with types and other > assumptions from kvm-unit-tests. In addition, this series adds support > for enumerating parts of the system using ACPI. > > The first set of patches, moves the existing ACPI code to the common > lib path. Then, it extends definitions and functions to allow for more > robust discovery of ACPI tables. We add support for setting up the PSCI > conduit, discovering the UART, timers, GIC and cpus via ACPI. The code > retains existing behavior and gives priority to discovery through DT > when one has been provided. > > In the second set of patches, we add support for getting the command > line from the EFI shell. This is a requirement for many of the > existing arm64 tests. > > In the third set of patches, we import code from gnu-efi, make minor > changes and add an alternative setup sequence from arm64 systems that > boot through EFI. Finally, we add support in the build system and a > run script which is used to run an EFI app. > > After this set of patches one can build arm64 EFI tests: > > $> ./configure --enable-efi > $> make > > And use the run script to run an EFI tests: > > $> ./arm/efi/run ./arm/selftest.efi -smp 2 -m 256 -append "setup smp=2 mem=256" > > Or all tests: > > $> ./run_tests.sh > > There are a few items that this series does not address but they would > be useful to have: > - Support for booting the system from EL2. Currently, we assume that a > test starts EL1. This will be required to run EFI tests on sytems > that implement EL2. > - Support for reading environment variables and populating __envp. > - Support for discovering the PCI subsystem using ACPI. > - Get rid of other assumptions (e.g., vmalloc area) that don't hold on > real HW. > - Various fixes related to cache maintaince to better support turn the > MMU off. > - Switch to a new stack and avoid relying on the one provided by EFI. > > git branch: https://gitlab.com/nnikoleris/kvm-unit-tests/-/tree/target-efi-upstream-v6 > > v5: https://lore.kernel.org/kvmarm/20230428120405.3770496-1-nikos.nikoleris@arm.com/ > v4: https://lore.kernel.org/kvmarm/20230213101759.2577077-1-nikos.nikoleris@arm.com/ > v3: https://lore.kernel.org/all/20220630100324.3153655-1-nikos.nikoleris@arm.com/ > v2: https://lore.kernel.org/kvm/20220506205605.359830-1-nikos.nikoleris@arm.com/ > > Changes in v6: > - Fixed a symbol issue in the debug tests that would cause them to fail > when build with fPIC. > - Added support for booting with FDT. > > Changes in v5: > - Minor style changes (thanks Shaoqin). > - Avoid including lib/acpi.o to cflatobjs twice (thanks Drew). > - Increase NR_INITIAL_MEM_REGIONS to avoid overflows and add check when > we run out of space (thanks Shaoqin). > > Changes in v4: > - Removed patch that reworks cache maintenance when turning the MMU > off. This is not strictly required for EFI tests running with tcg and > will be addressed in a separate series by Alex. > - Fix compilation for arm (Alex). > - Convert ACPI tables to Linux style (Alex). > > Changes in v3: > - Addressed feedback from Drew, Alex and Ricardo. Many thanks for the reviews! > - Added support for discovering the GIC through ACPI > - Added a missing header file (<elf.h>) > - Added support for correctly parsing the outcome of tests (./run_tests) > > Thanks, > > Nikos > Applied to arm/queue. Thanks! https://gitlab.com/jones-drew/kvm-unit-tests/-/commits/arm/queue drew
Hi Paolo and Sean, This series touches common ACPI code and even a bit of x86 code. Can I get an x86 ack on those bits? Thanks, drew On Tue, May 30, 2023 at 05:08:52PM +0100, Nikos Nikoleris wrote: > Hello, > > This series adds initial support for building arm64 tests as EFI > apps and running them under QEMU. Much like x86_64, we import external > dependencies from gnu-efi and adapt them to work with types and other > assumptions from kvm-unit-tests. In addition, this series adds support > for enumerating parts of the system using ACPI. > > The first set of patches, moves the existing ACPI code to the common > lib path. Then, it extends definitions and functions to allow for more > robust discovery of ACPI tables. We add support for setting up the PSCI > conduit, discovering the UART, timers, GIC and cpus via ACPI. The code > retains existing behavior and gives priority to discovery through DT > when one has been provided. > > In the second set of patches, we add support for getting the command > line from the EFI shell. This is a requirement for many of the > existing arm64 tests. > > In the third set of patches, we import code from gnu-efi, make minor > changes and add an alternative setup sequence from arm64 systems that > boot through EFI. Finally, we add support in the build system and a > run script which is used to run an EFI app. > > After this set of patches one can build arm64 EFI tests: > > $> ./configure --enable-efi > $> make > > And use the run script to run an EFI tests: > > $> ./arm/efi/run ./arm/selftest.efi -smp 2 -m 256 -append "setup smp=2 mem=256" > > Or all tests: > > $> ./run_tests.sh > > There are a few items that this series does not address but they would > be useful to have: > - Support for booting the system from EL2. Currently, we assume that a > test starts EL1. This will be required to run EFI tests on sytems > that implement EL2. > - Support for reading environment variables and populating __envp. > - Support for discovering the PCI subsystem using ACPI. > - Get rid of other assumptions (e.g., vmalloc area) that don't hold on > real HW. > - Various fixes related to cache maintaince to better support turn the > MMU off. > - Switch to a new stack and avoid relying on the one provided by EFI. > > git branch: https://gitlab.com/nnikoleris/kvm-unit-tests/-/tree/target-efi-upstream-v6 > > v5: https://lore.kernel.org/kvmarm/20230428120405.3770496-1-nikos.nikoleris@arm.com/ > v4: https://lore.kernel.org/kvmarm/20230213101759.2577077-1-nikos.nikoleris@arm.com/ > v3: https://lore.kernel.org/all/20220630100324.3153655-1-nikos.nikoleris@arm.com/ > v2: https://lore.kernel.org/kvm/20220506205605.359830-1-nikos.nikoleris@arm.com/ > > Changes in v6: > - Fixed a symbol issue in the debug tests that would cause them to fail > when build with fPIC. > - Added support for booting with FDT. > > Changes in v5: > - Minor style changes (thanks Shaoqin). > - Avoid including lib/acpi.o to cflatobjs twice (thanks Drew). > - Increase NR_INITIAL_MEM_REGIONS to avoid overflows and add check when > we run out of space (thanks Shaoqin). > > Changes in v4: > - Removed patch that reworks cache maintenance when turning the MMU > off. This is not strictly required for EFI tests running with tcg and > will be addressed in a separate series by Alex. > - Fix compilation for arm (Alex). > - Convert ACPI tables to Linux style (Alex). > > Changes in v3: > - Addressed feedback from Drew, Alex and Ricardo. Many thanks for the reviews! > - Added support for discovering the GIC through ACPI > - Added a missing header file (<elf.h>) > - Added support for correctly parsing the outcome of tests (./run_tests) > > Thanks, > > Nikos > > Alexandru Elisei (2): > lib/acpi: Convert table names to Linux style > lib: arm: Print test exit status > > Andrew Jones (2): > arm/arm64: Rename etext to _etext > arm64: Add a new type of memory type flag MR_F_RESERVED > > Nikos Nikoleris (28): > lib: Move acpi header and implementation to lib > x86: Move x86_64-specific EFI CFLAGS to x86_64 Makefile > lib: Apply Lindent to acpi.{c,h} > lib: Fix style for acpi.{c,h} > x86: Avoid references to fields of ACPI tables > lib/acpi: Ensure all struct definition for ACPI tables are packed > lib/acpi: Add support for the XSDT table > lib/acpi: Extend the definition of the FADT table > devicetree: Check that fdt is not NULL in dt_available() > arm64: Add support for setting up the PSCI conduit through ACPI > arm64: Add support for discovering the UART through ACPI > arm64: Add support for timer initialization through ACPI > arm64: Add support for cpu initialization through ACPI > arm64: Add support for gic initialization through ACPI > lib/printf: Support for precision modifier in printf > lib/printf: Add support for printing wide strings > lib/efi: Add support for getting the cmdline > lib/efi: Add support for reading an FDT > lib: Avoid ms_abi for calls related to EFI on arm64 > arm64: Add a setup sequence for systems that boot through EFI > arm64: Copy code from GNU-EFI > arm64: Change GNU-EFI imported code to use defined types > arm64: Use code from the gnu-efi when booting with EFI > lib: Avoid external dependency in libelf > arm64: Add support for efi in Makefile > arm64: debug: Make inline assembly symbols global > arm64: Add an efi/run script > arm64: Use the provided fdt when booting through EFI > > scripts/runtime.bash | 13 +- > arm/efi/run | 70 +++++++++ > arm/run | 14 +- > configure | 17 +- > Makefile | 4 - > arm/Makefile.arm | 6 + > arm/Makefile.arm64 | 22 ++- > arm/Makefile.common | 47 ++++-- > x86/Makefile.common | 2 +- > x86/Makefile.x86_64 | 4 + > lib/linux/efi.h | 126 +++++++++++++++ > lib/arm/asm/setup.h | 9 ++ > lib/arm/asm/timer.h | 2 + > lib/x86/asm/setup.h | 2 +- > lib/acpi.h | 302 ++++++++++++++++++++++++++++++++++++ > lib/argv.h | 1 + > lib/efi.h | 12 ++ > lib/elf.h | 57 +++++++ > lib/libcflat.h | 1 + > lib/x86/acpi.h | 112 ------------- > lib/acpi.c | 129 +++++++++++++++ > lib/argv.c | 2 +- > lib/arm/gic.c | 139 ++++++++++++++++- > lib/arm/io.c | 41 ++++- > lib/arm/mmu.c | 4 + > lib/arm/psci.c | 37 ++++- > lib/arm/setup.c | 284 +++++++++++++++++++++++++++------ > lib/arm/timer.c | 92 +++++++++++ > lib/devicetree.c | 2 +- > lib/efi.c | 222 ++++++++++++++++++++++++++ > lib/printf.c | 194 +++++++++++++++++++++-- > lib/x86/acpi.c | 82 ---------- > lib/x86/setup.c | 2 +- > arm/efi/elf_aarch64_efi.lds | 63 ++++++++ > arm/flat.lds | 2 +- > arm/cstart.S | 1 + > arm/cstart64.S | 7 + > arm/efi/crt0-efi-aarch64.S | 141 +++++++++++++++++ > arm/debug.c | 20 ++- > arm/dummy.c | 12 ++ > arm/efi/reloc_aarch64.c | 94 +++++++++++ > arm/micro-bench.c | 4 +- > arm/timer.c | 10 +- > x86/s3.c | 21 +-- > x86/vmexit.c | 4 +- > 45 files changed, 2102 insertions(+), 330 deletions(-) > create mode 100755 arm/efi/run > create mode 100644 lib/acpi.h > create mode 100644 lib/elf.h > delete mode 100644 lib/x86/acpi.h > create mode 100644 lib/acpi.c > create mode 100644 lib/arm/timer.c > delete mode 100644 lib/x86/acpi.c > create mode 100644 arm/efi/elf_aarch64_efi.lds > create mode 100644 arm/efi/crt0-efi-aarch64.S > create mode 100644 arm/dummy.c > create mode 100644 arm/efi/reloc_aarch64.c > > -- > 2.25.1 >
> On May 30, 2023, at 9:08 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: > > Hello, > > This series adds initial support for building arm64 tests as EFI > apps and running them under QEMU. Much like x86_64, we import external > dependencies from gnu-efi and adapt them to work with types and other > assumptions from kvm-unit-tests. In addition, this series adds support > for enumerating parts of the system using ACPI. Just an issue I encountered, which I am not sure is arm64 specific: All the printf’s in efi_main() are before current_thread_info() is initialized (or even memset’d to zero, as done in setup_efi). But printf() calls puts() which checks if mmu_enabled(). And mmu_enabled() uses is_user() and current_thread_info()->cpu, both of which read uninitialized data from current_thread_info(). IOW: Any printf in efi_main() can cause a crash.
On Sat, Jun 10, 2023 at 01:32:59AM -0700, Nadav Amit wrote: > > > On May 30, 2023, at 9:08 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: > > > > Hello, > > > > This series adds initial support for building arm64 tests as EFI > > apps and running them under QEMU. Much like x86_64, we import external > > dependencies from gnu-efi and adapt them to work with types and other > > assumptions from kvm-unit-tests. In addition, this series adds support > > for enumerating parts of the system using ACPI. > > Just an issue I encountered, which I am not sure is arm64 specific: > > All the printf’s in efi_main() are before current_thread_info() is > initialized (or even memset’d to zero, as done in setup_efi). > > But printf() calls puts() which checks if mmu_enabled(). And > mmu_enabled() uses is_user() and current_thread_info()->cpu, both > of which read uninitialized data from current_thread_info(). > > IOW: Any printf in efi_main() can cause a crash. > Nice catch, Nadav. Nikos, shouldn't we drop the memset() in setup_efi and put a zero_range call, similar to the one in arm/cstart64.S which zero's the thread-info area, in arm/efi/crt0-efi-aarch64.S? Thanks, drew
On 12/06/2023 08:52, Andrew Jones wrote: > On Sat, Jun 10, 2023 at 01:32:59AM -0700, Nadav Amit wrote: >> >>> On May 30, 2023, at 9:08 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: >>> >>> Hello, >>> >>> This series adds initial support for building arm64 tests as EFI >>> apps and running them under QEMU. Much like x86_64, we import external >>> dependencies from gnu-efi and adapt them to work with types and other >>> assumptions from kvm-unit-tests. In addition, this series adds support >>> for enumerating parts of the system using ACPI. >> >> Just an issue I encountered, which I am not sure is arm64 specific: >> >> All the printf’s in efi_main() are before current_thread_info() is >> initialized (or even memset’d to zero, as done in setup_efi). >> >> But printf() calls puts() which checks if mmu_enabled(). And >> mmu_enabled() uses is_user() and current_thread_info()->cpu, both >> of which read uninitialized data from current_thread_info(). >> >> IOW: Any printf in efi_main() can cause a crash. >> > > Nice catch, Nadav. Nikos, shouldn't we drop the memset() in setup_efi and > put a zero_range call, similar to the one in arm/cstart64.S which zero's > the thread-info area, in arm/efi/crt0-efi-aarch64.S? > While I haven't run into any problems with this in this series, I had in a previous version and back then the solution was this patch: 993c37be - arm/arm64: Zero BSS and stack at startup So I agree we should drop the memset and call some macro like zero_range in arm/efi/crt0-efi-aarch64.S. Let me know if you want me to send a patch for this. Thanks, Nikos
On Mon, Jun 12, 2023 at 10:52:00AM +0100, Nikos Nikoleris wrote: > On 12/06/2023 08:52, Andrew Jones wrote: > > On Sat, Jun 10, 2023 at 01:32:59AM -0700, Nadav Amit wrote: > > > > > > > On May 30, 2023, at 9:08 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: > > > > > > > > Hello, > > > > > > > > This series adds initial support for building arm64 tests as EFI > > > > apps and running them under QEMU. Much like x86_64, we import external > > > > dependencies from gnu-efi and adapt them to work with types and other > > > > assumptions from kvm-unit-tests. In addition, this series adds support > > > > for enumerating parts of the system using ACPI. > > > > > > Just an issue I encountered, which I am not sure is arm64 specific: > > > > > > All the printf’s in efi_main() are before current_thread_info() is > > > initialized (or even memset’d to zero, as done in setup_efi). > > > > > > But printf() calls puts() which checks if mmu_enabled(). And > > > mmu_enabled() uses is_user() and current_thread_info()->cpu, both > > > of which read uninitialized data from current_thread_info(). > > > > > > IOW: Any printf in efi_main() can cause a crash. > > > > > > > Nice catch, Nadav. Nikos, shouldn't we drop the memset() in setup_efi and > > put a zero_range call, similar to the one in arm/cstart64.S which zero's > > the thread-info area, in arm/efi/crt0-efi-aarch64.S? > > > > While I haven't run into any problems with this in this series, We're fine on QEMU, since QEMU zeros the memory. > I had in a > previous version and back then the solution was this patch: > > 993c37be - arm/arm64: Zero BSS and stack at startup > > So I agree we should drop the memset and call some macro like zero_range in > arm/efi/crt0-efi-aarch64.S. > > Let me know if you want me to send a patch for this. Yes, please, but we also don't have to hold this series up by it, since we agreed that this series was focused on EFI over QEMU as a first step. We'll need to worry about zeroing memory and more when we start running on bare-metal. To be clear, the patch for this can be on top of this series. Thanks, drew
On 12/06/2023 11:41, Andrew Jones wrote: >> Let me know if you want me to send a patch for this. > > Yes, please, but we also don't have to hold this series up by it, since we > agreed that this series was focused on EFI over QEMU as a first step. > We'll need to worry about zeroing memory and more when we start running > on bare-metal. > > To be clear, the patch for this can be on top of this series. > Thanks. I'll add this as a todo for the next series. Thanks, Nikos
> On Jun 12, 2023, at 2:52 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: > > On 12/06/2023 08:52, Andrew Jones wrote: >> On Sat, Jun 10, 2023 at 01:32:59AM -0700, Nadav Amit wrote: >>> >>>> On May 30, 2023, at 9:08 AM, Nikos Nikoleris <nikos.nikoleris@arm.com> wrote: >>>> >>>> Hello, >>>> >>>> This series adds initial support for building arm64 tests as EFI >>>> apps and running them under QEMU. Much like x86_64, we import external >>>> dependencies from gnu-efi and adapt them to work with types and other >>>> assumptions from kvm-unit-tests. In addition, this series adds support >>>> for enumerating parts of the system using ACPI. >>> >>> Just an issue I encountered, which I am not sure is arm64 specific: >>> >>> All the printf’s in efi_main() are before current_thread_info() is >>> initialized (or even memset’d to zero, as done in setup_efi). >>> >>> But printf() calls puts() which checks if mmu_enabled(). And >>> mmu_enabled() uses is_user() and current_thread_info()->cpu, both >>> of which read uninitialized data from current_thread_info(). >>> >>> IOW: Any printf in efi_main() can cause a crash. >>> >> Nice catch, Nadav. Nikos, shouldn't we drop the memset() in setup_efi and >> put a zero_range call, similar to the one in arm/cstart64.S which zero's >> the thread-info area, in arm/efi/crt0-efi-aarch64.S? > > While I haven't run into any problems with this in this series, I had in a previous version and back then the solution was this patch: > > 993c37be - arm/arm64: Zero BSS and stack at startup > > So I agree we should drop the memset and call some macro like zero_range in arm/efi/crt0-efi-aarch64.S. > > Let me know if you want me to send a patch for this. Thanks. I am still struggling to run the tests on my environment. Why the heck frame-pointers are disabled on arm64? Perhaps I’ll send my patch to enable them (and add one on exception handling). Anyhow, I was wondering, since it was not clearly mentioned in the cover-letter: which tests were run on what environment? Did they all pass or are there still some open issues? [ I ask for my enabling efforts. Not blaming or anything. ] Thanks again for the hard work, Nikos (and Andrew).
On 12/06/2023 16:59, Nadav Amit wrote:> > Thanks. I am still struggling to run the tests on my environment. Why the > heck frame-pointers are disabled on arm64? Perhaps I’ll send my patch to > enable them (and add one on exception handling). > I am afraid I don't know why it's omitted. It seems that x86 and arm keep it: $> git grep KEEP_FRAME_POINTER Makefile:frame-pointer-flag=-f$(if $(KEEP_FRAME_POINTER),no-,)omit-frame-pointer arm/Makefile.arm:KEEP_FRAME_POINTER := y x86/Makefile.common:KEEP_FRAME_POINTER := y It should be straightforward to add it for an arm64 build with debugging enabled, perhaps along with your other patch. > Anyhow, I was wondering, since it was not clearly mentioned in the > cover-letter: which tests were run on what environment? Did they all pass > or are there still some open issues? > > [ I ask for my enabling efforts. Not blaming or anything. ] > > Thanks again for the hard work, Nikos (and Andrew). > With this series and Drew's patch "arch-run: Extend timeout when booting with UEFI", on a standard Ubuntu 22.04.2 LTS (gcc version 11.3.0 and QEMU emulator version 6.2.0), I get the following results: $> ./run_tests.sh PASS selftest-setup (2 tests) PASS selftest-vectors-kernel (3 tests) PASS selftest-vectors-user (2 tests) PASS selftest-smp (1 tests) PASS pci-test (1 tests) PASS pmu-cycle-counter (2 tests) PASS pmu-event-introspection (1 tests) PASS pmu-event-counter-config (3 tests) PASS pmu-basic-event-count (11 tests, 1 skipped) PASS pmu-mem-access (3 tests, 1 skipped) PASS pmu-sw-incr (5 tests, 1 skipped) FAIL pmu-chained-counters (6 tests, 3 unexpected failures) FAIL pmu-chained-sw-incr (2 tests, 2 unexpected failures) FAIL pmu-chain-promotion (7 tests, 2 unexpected failures) FAIL pmu-overflow-interrupt (7 tests, 2 unexpected failures, 1 skipped) SKIP gicv2-ipi SKIP gicv2-mmio SKIP gicv2-mmio-up SKIP gicv2-mmio-3p PASS gicv3-ipi (3 tests) SKIP gicv2-active PASS gicv3-active (1 tests) PASS its-introspection (5 tests) PASS its-trigger (6 tests) SKIP its-migration SKIP its-pending-migration SKIP its-migrate-unmapped-collection PASS psci (5 tests, 1 skipped) PASS timer (18 tests) SKIP micro-bench (test marked as manual run only) PASS cache (1 tests) PASS debug-bp (6 tests) SKIP debug-bp-migration PASS debug-wp (8 tests) SKIP debug-wp-migration PASS debug-sstep (1 tests) SKIP debug-sstep-migration which is the same results I get when I build without --enable-efi, except for psci which requires ERRATA_6c7a5dce22b3=y to enable the cpu-on test. For this, I think we need to implement support for the ERRATA_* environmental variable. Thanks, Nikos
On Mon, Jun 12, 2023 at 10:53:56PM +0100, Nikos Nikoleris wrote: > On 12/06/2023 16:59, Nadav Amit wrote:> > > Thanks. I am still struggling to run the tests on my environment. Why the > > heck frame-pointers are disabled on arm64? Perhaps I’ll send my patch to > > enable them (and add one on exception handling). > > > > I am afraid I don't know why it's omitted. It seems that x86 and arm keep > it: The support was first added to x86 and then I ported it to arm and gave porting it to arm64 a small effort too, but it didn't work off the bat. I wrote it down on my TODO, but it eventually fell off the bottom... > > $> git grep KEEP_FRAME_POINTER > Makefile:frame-pointer-flag=-f$(if > $(KEEP_FRAME_POINTER),no-,)omit-frame-pointer > arm/Makefile.arm:KEEP_FRAME_POINTER := y > x86/Makefile.common:KEEP_FRAME_POINTER := y > > It should be straightforward to add it for an arm64 build with debugging > enabled, perhaps along with your other patch. > > > Anyhow, I was wondering, since it was not clearly mentioned in the > > cover-letter: which tests were run on what environment? Did they all pass > > or are there still some open issues? > > > > [ I ask for my enabling efforts. Not blaming or anything. ] > > > > Thanks again for the hard work, Nikos (and Andrew). > > > > With this series and Drew's patch "arch-run: Extend timeout when booting > with UEFI", on a standard Ubuntu 22.04.2 LTS (gcc version 11.3.0 and QEMU > emulator version 6.2.0), I get the following results: > > $> ./run_tests.sh > PASS selftest-setup (2 tests) > PASS selftest-vectors-kernel (3 tests) > PASS selftest-vectors-user (2 tests) > PASS selftest-smp (1 tests) > PASS pci-test (1 tests) > PASS pmu-cycle-counter (2 tests) > PASS pmu-event-introspection (1 tests) > PASS pmu-event-counter-config (3 tests) > PASS pmu-basic-event-count (11 tests, 1 skipped) > PASS pmu-mem-access (3 tests, 1 skipped) > PASS pmu-sw-incr (5 tests, 1 skipped) > FAIL pmu-chained-counters (6 tests, 3 unexpected failures) > FAIL pmu-chained-sw-incr (2 tests, 2 unexpected failures) > FAIL pmu-chain-promotion (7 tests, 2 unexpected failures) > FAIL pmu-overflow-interrupt (7 tests, 2 unexpected failures, 1 skipped) > SKIP gicv2-ipi > SKIP gicv2-mmio > SKIP gicv2-mmio-up > SKIP gicv2-mmio-3p > PASS gicv3-ipi (3 tests) > SKIP gicv2-active > PASS gicv3-active (1 tests) > PASS its-introspection (5 tests) > PASS its-trigger (6 tests) > SKIP its-migration > SKIP its-pending-migration > SKIP its-migrate-unmapped-collection > PASS psci (5 tests, 1 skipped) > PASS timer (18 tests) > SKIP micro-bench (test marked as manual run only) > PASS cache (1 tests) > PASS debug-bp (6 tests) > SKIP debug-bp-migration > PASS debug-wp (8 tests) > SKIP debug-wp-migration > PASS debug-sstep (1 tests) > SKIP debug-sstep-migration > > which is the same results I get when I build without --enable-efi, except > for psci which requires ERRATA_6c7a5dce22b3=y to enable the cpu-on test. For > this, I think we need to implement support for the ERRATA_* environmental > variable. > On Fedora 36 with qemu-system-aarch64-6.2.0-17.fc36.x86_64 I have PASS selftest-setup (2 tests) PASS selftest-vectors-kernel (3 tests) PASS selftest-vectors-user (2 tests) PASS selftest-smp (1 tests) PASS pci-test (1 tests) PASS pmu-cycle-counter (2 tests) FAIL pmu-event-introspection (1 tests, 1 unexpected failures) PASS pmu-event-counter-config (3 tests) SKIP pmu-basic-event-count (2 tests, 2 skipped) SKIP pmu-mem-access (2 tests, 2 skipped) PASS pmu-sw-incr (5 tests, 1 skipped) SKIP pmu-chained-counters (1 tests, 1 skipped) SKIP pmu-chained-sw-incr (1 tests, 1 skipped) SKIP pmu-chain-promotion (1 tests, 1 skipped) SKIP pmu-overflow-interrupt (2 tests, 2 skipped) PASS gicv2-ipi (3 tests) PASS gicv2-mmio (17 tests, 1 skipped) FAIL gicv2-mmio-up (17 tests, 2 unexpected failures) FAIL gicv2-mmio-3p (17 tests, 3 unexpected failures) PASS gicv3-ipi (3 tests) PASS gicv2-active (1 tests) PASS gicv3-active (1 tests) PASS its-introspection (5 tests) PASS its-trigger (6 tests) PASS psci (5 tests, 1 skipped) PASS timer (18 tests) SKIP micro-bench (test marked as manual run only) PASS cache (1 tests) PASS debug-bp (6 tests) PASS debug-wp (8 tests) FAIL debug-sstep (1 tests, 1 unexpected failures) I had to drop all the migration tests from unittests.cfg since they were hanging. The debug-sstep test passes with a later QEMU. Skipping the psci test is for the same reason Nikos points out above. I diffed the logs and besides EFI tests having edk2 output, they matched. I get the same results with ACPI as DT, other than pci-test being skipped. I also ran a couple tests from u-boot with bootefi and they worked. Thanks, drew
> On Jun 13, 2023, at 4:21 AM, Andrew Jones <andrew.jones@linux.dev> wrote: > > On Mon, Jun 12, 2023 at 10:53:56PM +0100, Nikos Nikoleris wrote: >> On 12/06/2023 16:59, Nadav Amit wrote:> >>> Thanks. I am still struggling to run the tests on my environment. Why the >>> heck frame-pointers are disabled on arm64? Perhaps I’ll send my patch to >>> enable them (and add one on exception handling). >>> >> >> I am afraid I don't know why it's omitted. It seems that x86 and arm keep >> it: > > The support was first added to x86 and then I ported it to arm and gave > porting it to arm64 a small effort too, but it didn't work off the bat. > I wrote it down on my TODO, but it eventually fell off the bottom… Thanks. Don’t worry. I’ll send my implementation.
On Tue, May 30, 2023 at 05:08:52PM +0100, Nikos Nikoleris wrote: > Hello, > > This series adds initial support for building arm64 tests as EFI > apps and running them under QEMU. Much like x86_64, we import external > dependencies from gnu-efi and adapt them to work with types and other > assumptions from kvm-unit-tests. In addition, this series adds support > for enumerating parts of the system using ACPI. > > The first set of patches, moves the existing ACPI code to the common > lib path. Then, it extends definitions and functions to allow for more > robust discovery of ACPI tables. We add support for setting up the PSCI > conduit, discovering the UART, timers, GIC and cpus via ACPI. The code > retains existing behavior and gives priority to discovery through DT > when one has been provided. > > In the second set of patches, we add support for getting the command > line from the EFI shell. This is a requirement for many of the > existing arm64 tests. > > In the third set of patches, we import code from gnu-efi, make minor > changes and add an alternative setup sequence from arm64 systems that > boot through EFI. Finally, we add support in the build system and a > run script which is used to run an EFI app. > > After this set of patches one can build arm64 EFI tests: > > $> ./configure --enable-efi > $> make > > And use the run script to run an EFI tests: > > $> ./arm/efi/run ./arm/selftest.efi -smp 2 -m 256 -append "setup smp=2 mem=256" > > Or all tests: > > $> ./run_tests.sh > Hey Nikos, I've just merged this. Thanks for all your hard work and patience. Now we need to get it to work on bare-metal, starting with early zeroing of BSS and anything else we deferred from this review. Yay! drew