Re: [RFC PATCH] xen/arm: Introduce GICV3 Self Tests

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

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 <ayan.kumar.halder@xxxxxxx>
> > > > ---
> > > > 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