xen/arch/arm/Kconfig | 8 ++++++++ xen/arch/arm/gic-v3.c | 7 +++++++ xen/arch/arm/gic.c | 21 +++++++++++++++++++++ 3 files changed, 36 insertions(+)
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@amd.com>
---
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
+
out:
spin_unlock(&gicv3.lock);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index d922ea67aa..5cb58cdb92 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
*/
smp_rmb();
+#ifdef CONFIG_GICV3_SELFTEST
+ switch (sgi)
+ {
+ case GIC_SGI_EVENT_CHECK:
+ printk("GIC_SGI_EVENT_CHECK received\n");
+ break;
+ case GIC_SGI_DUMP_STATE:
+ printk("GIC_SGI_DUMP_STATE received\n");
+ break;
+ case GIC_SGI_CALL_FUNCTION:
+ printk("GIC_SGI_CALL_FUNCTION received\n");
+ break;
+ case GIC_SGI_MAX:
+ printk("GIC_SGI_MAX received\n");
+ break;
+ default:
+ panic("Unknown SGI triggered\n");
+ break;
+ }
+#else
switch (sgi)
{
case GIC_SGI_EVENT_CHECK:
@@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
break;
}
+#endif
/* Deactivate */
gic_hw_ops->deactivate_irq(desc);
--
2.25.1On Fri, 12 Sep 2025, 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@amd.com>
> ---
> 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.
I like this approach and I think it is OK if Xen is not functional after
some of the SELFTESTS because it is not the goal to run those in a
working system.
My only suggestion is to separate the SELFTESTS in a separate __init
function, keeping them isolated from the rest of the code, for simplicy
and also ease of understanding.
See for example stub_selftest.
> 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
> +
> out:
> spin_unlock(&gicv3.lock);
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index d922ea67aa..5cb58cdb92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> */
> smp_rmb();
>
> +#ifdef CONFIG_GICV3_SELFTEST
> + switch (sgi)
> + {
> + case GIC_SGI_EVENT_CHECK:
> + printk("GIC_SGI_EVENT_CHECK received\n");
> + break;
> + case GIC_SGI_DUMP_STATE:
> + printk("GIC_SGI_DUMP_STATE received\n");
> + break;
> + case GIC_SGI_CALL_FUNCTION:
> + printk("GIC_SGI_CALL_FUNCTION received\n");
> + break;
> + case GIC_SGI_MAX:
> + printk("GIC_SGI_MAX received\n");
> + break;
> + default:
> + panic("Unknown SGI triggered\n");
> + break;
> + }
> +#else
> switch (sgi)
> {
> case GIC_SGI_EVENT_CHECK:
> @@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
> break;
> }
> +#endif
>
> /* Deactivate */
> gic_hw_ops->deactivate_irq(desc);
> --
> 2.25.1
>
Hi Ayan,
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@amd.com>
> ---
> 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.
> out:
> spin_unlock(&gicv3.lock);
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index d922ea67aa..5cb58cdb92 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> */
> smp_rmb();
>
> +#ifdef CONFIG_GICV3_SELFTEST
if (gic_selftest_run)
> + switch (sgi)
> + {
> + case GIC_SGI_EVENT_CHECK:
> + printk("GIC_SGI_EVENT_CHECK received\n");
> + break;
> + case GIC_SGI_DUMP_STATE:
> + printk("GIC_SGI_DUMP_STATE received\n");
> + break;
> + case GIC_SGI_CALL_FUNCTION:
> + printk("GIC_SGI_CALL_FUNCTION received\n");
> + break;
> + case GIC_SGI_MAX:
> + printk("GIC_SGI_MAX received\n");
gic_selftest_done = true;
> + break;
> + default:
> + panic("Unknown SGI triggered\n");
> + break;
> + }
Potentially GIC selftest code can be guarded by some "gic_selftest_run/done" vars
if xen boot is expected to proceed further after testing.
> +#else
> switch (sgi)
> {
> case GIC_SGI_EVENT_CHECK:
> @@ -361,6 +381,7 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
> panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
> break;
> }
> +#endif
>
> /* Deactivate */
> gic_hw_ops->deactivate_irq(desc);
--
Best regards,
-grygorii
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@amd.com>
>> ---
>> 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
>
>> out:
>> spin_unlock(&gicv3.lock);
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index d922ea67aa..5cb58cdb92 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs,
>> enum gic_sgi sgi)
>> */
>> smp_rmb();
>> +#ifdef CONFIG_GICV3_SELFTEST
>
> if (gic_selftest_run)
And then instead of ifdef, I can enclose the below under "if
(gicv3_selftest)" .
>
>> + switch (sgi)
>> + {
>> + case GIC_SGI_EVENT_CHECK:
>> + printk("GIC_SGI_EVENT_CHECK received\n");
>> + break;
>> + case GIC_SGI_DUMP_STATE:
>> + printk("GIC_SGI_DUMP_STATE received\n");
>> + break;
>> + case GIC_SGI_CALL_FUNCTION:
>> + printk("GIC_SGI_CALL_FUNCTION received\n");
>> + break;
>> + case GIC_SGI_MAX:
>> + printk("GIC_SGI_MAX received\n");
>
> gic_selftest_done = true;
>
>> + break;
>> + default:
>> + panic("Unknown SGI triggered\n");
>> + break;
>> + }
>
> Potentially GIC selftest code can be guarded by some
> "gic_selftest_run/done" vars
> if xen boot is expected to proceed further after testing.
Ah no, Xen will terminate after running the self test.
- Ayan
Hi Ayan,
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@amd.com>
>>> ---
>>> 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
Then, gic SGI selftest might work without breaking Xen boot (probably for gicv2 also)
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)
}
>
>>
>>> out:
>>> spin_unlock(&gicv3.lock);
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index d922ea67aa..5cb58cdb92 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -346,6 +346,26 @@ static void do_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
>>> */
>>> smp_rmb();
>>> +#ifdef CONFIG_GICV3_SELFTEST
>>
>> if (gic_selftest_run)
> And then instead of ifdef, I can enclose the below under "if (gicv3_selftest)" .
>>
>>> + switch (sgi)
>>> + {
>>> + case GIC_SGI_EVENT_CHECK:
>>> + printk("GIC_SGI_EVENT_CHECK received\n");
>>> + break;
>>> + case GIC_SGI_DUMP_STATE:
>>> + printk("GIC_SGI_DUMP_STATE received\n");
>>> + break;
>>> + case GIC_SGI_CALL_FUNCTION:
>>> + printk("GIC_SGI_CALL_FUNCTION received\n");
>>> + break;
>>> + case GIC_SGI_MAX:
>>> + printk("GIC_SGI_MAX received\n");
>>
>> gic_selftest_done = true;
>>
>>> + break;
>>> + default:
>>> + panic("Unknown SGI triggered\n");
>>> + break;
>>> + }
>>
>> Potentially GIC selftest code can be guarded by some "gic_selftest_run/done" vars
>> if xen boot is expected to proceed further after testing.
>
> Ah no, Xen will terminate after running the self test.
>
> - Ayan
>
--
Best regards,
-grygorii
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@amd.com>
>>>> ---
>>>> 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
Hi Ayan, On 12/09/2025 18: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@amd.com> > --- > 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. To clarify, this only guarantees that the boot CPU can send SGIs to self. Secondary CPUs are brought up later and will need their own setup to enable 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 Looking a the code below, it seems like Xen will not be functional after running the selftests? Is this intended? If so, we need to stop Xen as soon as possible. Also, looking at start_xen(), we call local_irq_enable() a little after gicv3_init() is called. So I am a little bit surprised this is working? Cheers, -- Julien Grall
On 15/09/2025 12:14, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 12/09/2025 18: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@amd.com> >> --- >> 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. > > To clarify, this only guarantees that the boot CPU can send SGIs to self. Yes, this is the idea. > Secondary CPUs are brought up later and will need their own setup to > enable SGIs. Yes, we will have separate tests for them. > >> 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 > > Looking a the code below, it seems like Xen will not be functional > after running the selftests? Is this intended? If so, we need to stop > Xen as soon as possible. Tbh, I didnot realize this with the current test. However you are correct that for some of these tests, Xen will not be usable. We can put a while(1) after it completes the tests. Or, I can invoke machine_halt() . The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for normal usage of Xen. IOW, user should not expect Xen to run domains when this configuration is enabled. They are used to run baremetal tests. > > Also, looking at start_xen(), we call local_irq_enable() a little > after gicv3_init() is called. So I am a little bit surprised this is > working? This is working i.e. we are getting interrupts. However, I can put the test after local_irq_enable() as Xen is expected to terminate after running the tests. - Ayan > > Cheers, >
Hi Ayan, On 22/09/2025 17:40, Ayan Kumar Halder wrote: > > On 15/09/2025 12:14, Julien Grall wrote: >> Hi Ayan, > Hi Julien, >> >> On 12/09/2025 18: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@amd.com> >>> --- >>> 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. >> >> To clarify, this only guarantees that the boot CPU can send SGIs to self. > Yes, this is the idea. >> Secondary CPUs are brought up later and will need their own setup to >> enable SGIs. > Yes, we will have separate tests for them. >> >>> 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 >> >> Looking a the code below, it seems like Xen will not be functional >> after running the selftests? Is this intended? If so, we need to stop >> Xen as soon as possible. > > Tbh, I didnot realize this with the current test. However you are > correct that for some of these tests, Xen will not be usable. We can put > a while(1) after it completes the tests. > > Or, I can invoke machine_halt() . I think it would be better to use machine_halt(). This would tell QEMU to stop and hopefully we don't wait until it timeouts. > > The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for > normal usage of Xen. IOW, user should not expect Xen to run domains when > this configuration is enabled. > > They are used to run baremetal tests. > >> >> Also, looking at start_xen(), we call local_irq_enable() a little >> after gicv3_init() is called. So I am a little bit surprised this is >> working? > > This is working i.e. we are getting interrupts. However, I can put the > test after local_irq_enable() as Xen is expected to terminate after > running the tests. I don't understand how this is working. Can you check whether the interrupts are unmasked? If yes, it would be good to know who unmasked them because it is not meant to be safe to enable them until the call of local_irq_enable() in start_xen(). Cheers, -- Julien Grall
On 22/09/2025 18:22, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 22/09/2025 17:40, Ayan Kumar Halder wrote: >> >> On 15/09/2025 12:14, Julien Grall wrote: >>> Hi Ayan, >> Hi Julien, >>> >>> On 12/09/2025 18: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@amd.com> >>>> --- >>>> 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. >>> >>> To clarify, this only guarantees that the boot CPU can send SGIs to >>> self. >> Yes, this is the idea. >>> Secondary CPUs are brought up later and will need their own setup to >>> enable SGIs. >> Yes, we will have separate tests for them. >>> >>>> 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 >>> >>> Looking a the code below, it seems like Xen will not be functional >>> after running the selftests? Is this intended? If so, we need to >>> stop Xen as soon as possible. >> >> Tbh, I didnot realize this with the current test. However you are >> correct that for some of these tests, Xen will not be usable. We can >> put a while(1) after it completes the tests. >> >> Or, I can invoke machine_halt() . > > I think it would be better to use machine_halt(). This would tell QEMU > to stop and hopefully we don't wait until it timeouts. Ack. I agree. > >> >> The important bit here is CONFIG_GICV3_SELFTEST cannot be enabled for >> normal usage of Xen. IOW, user should not expect Xen to run domains >> when this configuration is enabled. >> >> They are used to run baremetal tests. >> >>> >>> Also, looking at start_xen(), we call local_irq_enable() a little >>> after gicv3_init() is called. So I am a little bit surprised this is >>> working? >> >> This is working i.e. we are getting interrupts. However, I can put >> the test after local_irq_enable() as Xen is expected to terminate >> after running the tests. > > I don't understand how this is working. Can you check whether the > interrupts are unmasked? If yes, it would be good to know who unmasked > them because it is not meant to be safe to enable them until the call > of local_irq_enable() in start_xen(). Yes, you are correct. I put a while(1) after local_irq_enable() and then I could see the interrupts. Before that, we do not get the SGIs. This means we should be doing this. local_irq_enable(); + + mdelay(1); /* to allow some time for interrupts to be received */ + machine_halt(); I will think of something to avoid ifdef in common code. May be write a wrapper for local_irq_enable() which will invoke the GICv3 self tests. - Ayan > > Cheers, >
© 2016 - 2026 Red Hat, Inc.