|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 for 4.23] Add GICv3 SGI boot/self tests in Xen
Hi Ayan, On 29/05/2026 18:09, Ayan Kumar Halder wrote: Boot self-tests (also referred to as boot-time tests or power-on self-tests) are intended to validate internal features of Xen during bring-up. They are meant to be run in a debug / validation environment; Xen is not expected to remain functional for production use after the self-tests have executed. Looking at the code below, isn't Xen functional even after the self-test? The purpose of these tests is to catch hardware configuration issues early and to confirm that the platform on which Xen has been brought up is sane. The expected flow is: build Xen with the self-tests enabled, boot it, inspect the results, and then reboot into the usual production configuration. Introduce the tests to confirm that: 1. A cpu can send SGI 0 to itself 2. A cpu can send SGI 0 to another specific CPU 3. A cpu can send SGI 0 to all the other CPUs 4. A cpu can send SGI 1 to another CPU I am not sure what you meant by SGI 0 and SGI 1? Below you seem to be use only a SGI (which is neither 0 or 1) except for one specific test: cpu 0 injecting an SGI to a specific CPU (0). These tests aim to test Xen has configured the GIC correctly to use SGIs. Thus, the tests invoke specific APIs of GIC driver. Also, introduce a config CONFIG_BOOT_SELFTEST which enables these tests. The option defaults to N; it should be disabled for production builds and is intended for the validation pipeline and coverage measurement. The tests run during Xen boot and validate internal interfaces such as Xen's interface with hardware, firmware and the bootloader. Also, introduce an integer command line parameter "gic-test". By default, it is set to 0 which means no tests are enabled. For running SGI tests, "gic-test" should be set to 1. In future if we add tests for distributer, ITS, LPI, etc, then we can use different numbers. Thus, each number denotes a functionality of GICv3 which can be tested independently and within a single boot of Xen. In this way, we ensure that the tests to validate SGIs do not impact any other tests. In order to keep all the boot-time self-tests together in the binary, we have introduced a separate section "initcallboottest". All the tests are registered using __initcallboottest. During the bootup of each core, Xen invokes do_init_boottests() to run the these tests. All these tests are invoked before Xen creates the domains (in case of primary core) or runs the idle loop (in case of secondary core). Note: it was suggested that, once the boot self-tests have run, Xen should call machine_halt() rather than continue booting (since this build is only intended for validation). This is not wired in here because the SGIs are sent from the primary and secondary CPUs and received asynchronously on the target CPUs. There is no definite point in the boot flow at which Xen can know that every send has been observed by its receiver, so "after the tests have completed" has no well-defined moment at which to insert machine_halt(). Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx> --- Link to v1 (RFC): https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00956.html Upstream CI run (xen-project/people/ayankuma/xen fork, one commit on top of xen-project/xen staging — all Linux builds + tests including qemu-smoke-boot-selftest-arm64-gcc-debug passed; only the macos jobs sit pending because the personal fork has no macos runner): https://gitlab.com/xen-project/people/ayankuma/xen/-/pipelines/2561806695 Changes in v2: - Renamed the patch from "xen/arm: Introduce GICV3 Self Tests" to "Add GICv3 SGI boot/self tests in Xen", and rewrote the commit message to explain the intent of boot self-tests (debug / validation builds only, Xen not expected to remain functional afterwards). - Moved the selftest code out of gic-v3.c into a dedicated file xen/arch/arm/gic-test.c, gated by CONFIG_BOOT_SELFTEST (Stefano, Grygorii). - Introduced a generic boot-self-test framework: new section "initcallboottest", registration macro __initcallboottest, and do_init_boottests() invoked once per CPU after local_irq_enable(), so the test runs on every CPU (boot + secondaries) and no longer collides with the IRQ-enable timing in gicv3_init() (Julien #1, Julien #3). - Added Kconfig option CONFIG_BOOT_SELFTEST in xen/arch/arm/Kconfig (arm-only for now; arch-specific because the only registered test is GICv3-specific). - Reserved a dedicated SGI value GIC_SGI_TEST in enum gic_sgi (xen/arch/arm/include/asm/gic.h), so the selftest never reuses a functional SGI (Grygorii #3). - Added a runtime integer command-line parameter "gic-test" so the selftest binary can be shipped but its execution selected at boot (gic-test=0 -> no-op; gic-test=1 -> SGI tests). Future GICv3 features (distributor, ITS, LPI, ...) can claim further values (Grygorii #2, partial). - Documented why machine_halt() is not invoked after the tests: SGI delivery is asynchronous, so there is no well-defined point after which every send has been observed by its receiver (Julien #2). - Wired the tests into upstream GitLab CI: new build job alpine-3.18-gcc-debug-arm64-boot-selftest, new test job qemu-smoke-boot-selftest-arm64-gcc-debug, and the runner script automation/scripts/qemu-boot-selftest-arm64.sh that dumps the QEMU virt DTB, injects "gic-test=1 console=dtuart sync_console" into /chosen/xen,xen-bootargs via fdtput, boots Xen, and checks for each "Sending GIC_SGI_TEST ..." followed by the matching "CPU%u: GIC_SGI_TEST received". automation/gitlab-ci/build.yaml | 8 ++ automation/gitlab-ci/test.yaml | 8 ++ .../scripts/qemu-boot-selftest-arm64.sh | 81 +++++++++++++++++++ xen/arch/arm/Kconfig | 15 ++++ xen/arch/arm/Makefile | 1 + xen/arch/arm/gic-test.c | 52 ++++++++++++ xen/arch/arm/gic.c | 5 ++ xen/arch/arm/include/asm/gic.h | 3 + xen/arch/arm/setup.c | 2 + xen/arch/arm/smpboot.c | 2 + xen/arch/arm/xen.lds.S | 4 + xen/common/kernel.c | 11 +++ xen/include/xen/init.h | 3 + 13 files changed, 195 insertions(+) create mode 100755 automation/scripts/qemu-boot-selftest-arm64.sh create mode 100644 xen/arch/arm/gic-test.c diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 7f5b5938e8..8df45caa86 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -439,6 +439,14 @@ alpine-3.18-gcc-debug-arm64: CONFIG_UBSAN=y CONFIG_UBSAN_FATAL=y+alpine-3.18-gcc-debug-arm64-boot-selftest: This means that there is no much difference between "send an SGI to a specific CPU" and "send an SGI to others CPU". I think it would be more meaningful to use 3 or more pCPUs.
Above you said, this is not meant for production. So I was expecting to see a dependency on CONFIG_DEBUG. If the intention is to use it in release build, given the current behavior (e.g. breaking test), I think this should depend on UNSUPPORTED so we don't get security report because Xen is broken after the boot tests. > + help> + This option enables boot-time self-tests that validate Xen's internal + interfaces with hardware, firmware and the bootloader. The tests are + registered with __initcallboottest and executed by do_init_boottests() + during early boot, before domains are created. + + These tests are intended for validation and coverage measurement, not + for production builds. With this option enabled, Xen may not be + functional after the tests have run. If we know a test break, I think it is best that Xen doesn't continue. Otherwise, it is quite confusing for the user to know what's going on. My preference is the bootest would act like other self tests and Xen can continue booting normally. So the tests could also be meaningful in non-test setups. + + If unsure, say N. + source "arch/arm/platforms/Kconfig"source "common/Kconfig"diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 84c4062b30..0090761682 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -24,6 +24,7 @@ obj-y += domctl.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o obj-y += efi/ obj-y += gic.o +obj-$(CONFIG_BOOT_SELFTEST) += gic-test.init.o obj-$(CONFIG_GICV2) += gic-v2.o obj-$(CONFIG_GICV3) += gic-v3.o obj-$(CONFIG_HAS_ITS) += gic-v3-its.o diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c new file mode 100644 index 0000000000..ca922e5d2a --- /dev/null +++ b/xen/arch/arm/gic-test.c @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include <xen/delay.h> +#include <xen/init.h> +#include <xen/param.h> +#include <xen/shutdown.h> Can you clarify why you need this header? Given this is mean to be 0 or 1, why not using "boolean_param"?Also, new command line option should be documented in the docs. That said, I am not really sure about OOI, why is this only called for CPU0? You also don't seem to check that smp_send_state_dump() in the CI test. This is relying on how Xen is boot CPUs. Would it be better to check the number of online CPUs at the time of the check? (You might need to re-order some code for that) To confirm, we will solely rely on logging? IOW, there is no plan to have Xen self-sufficient (e.g. using a global variable).
I think it would be worth printing before and after to indicate the begin/end of the selftest.
Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |