On 24/09/2025 16:48, Grygorii Strashko wrote:
Hi Ayan,
Hi Grygorii,
On 22.09.25 19:55, Ayan Kumar Halder wrote:
On 16/09/2025 11:55, Grygorii Strashko wrote:
Hi Ayan,
Hi Grygorii,
On 12.09.25 20:00, Ayan Kumar Halder wrote:
Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
Test that Xen is able to generate SGIs.
Signed-off-by: Ayan Kumar Halder <[email protected]>
---
One of the aim of functional safety is to test hw/sw interface.
This means that
Xen is able to configure the hardware correctly for the desired
functionalities.
Normally this is tested from the VMs. For eg if a VM is able to
receive irq, this
implies that Xen has configured the GICv3 interface 'correctly'.
However this is
a high level (or integration) test which uses not only the GICv3
interface
between Xen and VM, but the interrupt injection code for Xen to VMs.
We want to have some kind of unit tests to check that Xen is able
to receive
various interrupts, set priorities, etc. Here, we have written unit
tests for
software generated interrupts (SGIs) as example.
These tests are expected to be triggered as Xen boots (right after
Xen has
initialised the GICv3 interface ie gicv3_init(). The aim of this
test is to
check whether Xen can trigger SGIs after gicv3_init() is invoked.
If so, we can
claim that gicv3_init() was done properly to be able to trigger
SGIs. Likewise
we will have tests to check for priorities, SPIs, etc.
A script will parse the logs and claim that Xen is able to trigger
SGIs.
xen/arch/arm/Kconfig | 8 ++++++++
xen/arch/arm/gic-v3.c | 7 +++++++
xen/arch/arm/gic.c | 21 +++++++++++++++++++++
3 files changed, 36 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 950e4452c1..739f99eaa9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,14 @@ config GICV3
Driver for the ARM Generic Interrupt Controller v3.
If unsure, use the default setting.
+config GICV3_SELFTEST
+ bool "GICv3 driver self test"
+ default n
+ depends on GICV3
+ ---help---
+
+ Self tests to validate GICV3 driver.
+
config HAS_ITS
bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if
UNSUPPORTED
depends on GICV3 && !NEW_VGIC && !ARM_32
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4e6c98bada..eb0c05231c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1818,6 +1818,13 @@ static int __init gicv3_init(void)
gicv3_hyp_init();
+#ifdef CONFIG_GICV3_SELFTEST
+ send_SGI_self(GIC_SGI_EVENT_CHECK);
+ send_SGI_self(GIC_SGI_DUMP_STATE);
+ send_SGI_self(GIC_SGI_CALL_FUNCTION);
+ send_SGI_self(GIC_SGI_MAX);
+#endif
+
I'd like to ask, if possible, to minimize mixing selftest and
functional code.
Like add gic-v3-selftest.c.
I can try that. However, the self test needs to be invoked from
functional code.
Also, your suggestion gave me an idea. I can do :-
+static bool __initdata opt_gicv3_selftest = false;
+
+#ifdef CONFIG_GICV3_SELFTEST
+opt_gicv3_selftest = true;
+#endif
I'd like to propose to consider other approach according to the
following assumptions:
1) the goal is "Test that Xen is able to generate SGIs.". According to
the goal and your code
- for this test, it doesn't matter which one (SGI) is tested. Any way
you don't call real handlers for
GIC_SGI_x.
2) there are 16 SGIs available, only 3 are statistically defined (enum
gic_sgi) and
It's possible to reserve one more for testing purposes,
like GIC_SGI_SELFTEST
I do like this approach. The only mild concern is that the test
introduces a new SGI. IOW, it is not testing the existing SGIs which are
used by Xen.
I need to think a bit more on this.
Then, gic SGI selftest might work without breaking Xen boot (probably
for gicv2 also)
The goal of these kind of self tests are to validate Xen drivers (or
rather Xen's configuration of the HW component). We will not be running
Xen with any domains. Also, we don't intend to have the self tests run
during regular boot of Xen as it adds a significant amount of code to be
executed during boot time.
These tests will help to isolate issues when there is a potential
misconfiguration of Xen for the hardware component or the hardware
component does not work correctly with Xen.
gic.c:
do_static_sgi()
{
...
#ifdef CONFIG_GIC_SELFTEST
case GIC_SGI_SELFTEST:
gic_sgi_selftest();
break;
#endif
git-selftest.c
gic_sgi_selftest()
{
// process test SGI, like count number of triggers
}
void [__init __constructor?] test_gic_sgi_selftest()
{
setup test 1
send_SGI_self(GIC_SGI_SELFTEST)
setup test 2
send_SGI_allbutself(GIC_SGI_SELFTEST)
setup test 2
send_SGI_mask(cpu_mask, GIC_SGI_SELFTEST)
}
I do like the coding suggestion.
- Ayan
