Re: [PATCH v2] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS

[Julien Grall <julien@xxxxxxx>]

Hi Ayan,

On 18/04/2026 08:28, Halder, Ayan Kumar wrote:
> On 14/04/2026 03:06, Julien Grall wrote:
> > Hi Ayan,
> Hi Julien,
> > On 18/03/2026 23:09, Ayan Kumar Halder wrote:
> > > One key requirement of Xen functional safety is to reduce the number
> > > of lines of code to be safety certified. Besides, a safety certified
> > > Xen requires a static hardware configuration to be defined. This static
> > > hardware configuration is described as per the test hardware/emulator
> > > hardware configuration against which Xen is verified.
> > >
> > > Introduce GICV3_NR_LRS with the two aims in mind:
> > Out of interest, why is this limited to GICv3?
> This was just my starting point of investigation. My intention is to 
> have as much as a static defined hardware configuration, so that the 
> code that cannot be tested on the hardware can be eliminated by one of 
> the many ways (DCE, Kconfig or actual code removal).
> The advantage of having a static defined configuration is that the 
> system integrator will have the full control on how to configure Xen for 
> a specific hardware platform. And we try to reduce as much as possible 
> any code that cannot be used due to hardware limitations.
Thanks for the answer. I was asking because I wonder whether the name of 
config should be more generic so it can be used for GICV2. But I guess 
we can rename it afterwards.
> > > 1. User should set the number of GICV3 list registers as per the test
> > > hardware so that the unwanted code can be removed using GCC's dead
> > > code elimination or preprocessor's config.
> > We discussed this offline, I am not fully convinced you can rely on 
> > dead code elimination to always remove the BUG() in 
> > gicv3_ich_read_lr(). If you want to rely on dead code eliminitation, 
> > then you will want to call a function which have a prototype defined 
> > but not implemented (similar to what we do for bitops with 
> > __bad_atomic_read()) which would fail a link time if the compiler 
> > didn't remove the code.
> If you are ok, we can break this into 2 patches
>
> 1. Introduce GICV3_NR_LRS and make sure it is used consistently in the 
> code. IOW, it should address the comments that Luca and you provided.
> 2. Implement a way for compiler to do DCE based on GICV3_NR_LRS.
Yes please, so we can merge patch #1 earlier.

> > > 2. By doing #1, one can ensure that there is no untested code due to
> > > unsupported hardware platform and thus there is no safety impact due
> > > to untested code.
> > >
> > > However if the user does not set GICV3_NR_LRS, then it is set to 0.
> > > Thus Xen will fallback to the default scenario (i.e. read the hardware
> > > register to determine the number of LRS).
> > >
> > > 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list
> > > registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs.
> > > This ensures that if the hardware does not support more than 4 LRs
> > > (for example), the code accessing LR 4-15 is never reached. The
> > > compiler can eliminate the unsupported cases as the switch case uses a
> > > constant conditional.
> > >
> > > 2. RAZ/WI for the unsupported LRs.
> > >
> > > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
> > > Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> > > ---
> > > Changelog:
> > >
> > > v1 - 1. s/lrs/LRS
> > > 2. Implement RAZ/WI instead of panic
> > >
> > > Few comments which were not addressed
> > > 1. Do "gicv3_info.nr_lrs to LRS" in gicv3_hyp_init() and keep the code
> > > unchanged in gicv3_save_lrs()/gicv3_restore_lrs() -- This prevents the
> > > compiler from doing dead code elimination as the switch condition cannot
> > > be evaluated at compile time.
> > > I am not sure how to get around this issue.
> > >
> > >   xen/arch/arm/Kconfig  |  9 +++++++++
> > >   xen/arch/arm/gic-v3.c | 14 ++++++++++++--
> > >   2 files changed, 21 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > index 2f2b501fda..6540013f97 100644
> > > --- a/xen/arch/arm/Kconfig
> > > +++ b/xen/arch/arm/Kconfig
> > > @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH
> > >     endmenu
> > >   +config GICV3_NR_LRS
> > > +    int "Number of GICv3 Link Registers supported" if EXPERT
> > Supported by who? The hardware? Xen? Asking, because I could forsee an 
> > integrator wanted to limit the number of LRs to something smaller than 
> > what the HW supports (in a lot of cases, 2 LRs is sufficient).
> Ack
>
>   ... "Number of GICv3 Link Registers used" if EXPERT
>
> So it implies a decision to be taken by the system integrator. Does it 
> sound ok ?
Either "used" or "allowed" would be fine.

Cheers,

--
Julien Grall