Re: [Xen-devel] [PATCH 04/57] ARM: GICv3: simplify GICv3 redistributor stride handling

[Julien Grall <julien.grall@xxxxxxx>]

On 05/03/18 17:08, Julien Grall wrote:
> On 05/03/18 16:03, Andre Przywara wrote:
> > Instead of hard coding the architected redistributor stride into the
> > code, lets use a clear #define to the two values for GICv3 and GICv4 and
> > clarify the algorithm to determine the needed stride value.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
> > ---
> > Changelog RFC ... v1:
> > - no changes
> >
> >   xen/arch/arm/gic-v3.c             | 18 ++++++++++--------
> >   xen/include/asm-arm/gic_v3_defs.h |  5 +++++
> >   2 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> > index b1f8a86409..be1787b39a 100644
> > --- a/xen/arch/arm/gic-v3.c
> > +++ b/xen/arch/arm/gic-v3.c
> > @@ -690,6 +690,15 @@ static int __init gicv3_populate_rdist(void)
> >           do {
> >               typer = readq_relaxed(ptr + GICR_TYPER);
> > +            /* Set the architectural redist size if not overridden by 
> > DT. */
> > +            if ( !gicv3.rdist_stride )
> > +            {
> > +                if ( typer & GICR_TYPER_VLPIS )
> Is there anything in the spec promising you that *all* the 
> redistributors will support vLPIs?
Answering to myself, Marc pointed out that nothing was promising all 
redistributors will support vLPIs. This is confirmed by the section 9.7 
"Mixing GICv3 and GICv4" in "GICv3 and GICv4 Software Overview" DAI 0492B.
So I would prefer to drop that patch and move GICV*_GICR_SIZE definition 
in patch #5. I am assuming we will never expose a mix of GICv3/GICv4 on Xen.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel