Re: [PATCH v2 02/27] ARM: GICv3: allocate LPI pending and property table

[Stefano Stabellini <sstabellini@kernel.org>]

On Thu, 23 Mar 2017, Julien Grall wrote:
> On 23/03/17 14:40, Andre Przywara wrote:
> > Hi,
> 
> Hi Andre,
> 
> > 
> > On 21/03/17 21:23, Julien Grall wrote:
> > > Hi Andre,
> > > 
> > > On 03/16/2017 11:20 AM, Andre Przywara wrote:
> > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > > index bf64c61..86f7b53 100644
> > > > --- a/xen/arch/arm/Kconfig
> > > > +++ b/xen/arch/arm/Kconfig
> > > > @@ -49,6 +49,21 @@ config HAS_ITS
> > > >          bool "GICv3 ITS MSI controller support"
> > > >          depends on HAS_GICV3
> > > > 
> > > > +config MAX_PHYS_LPI_BITS
> > > > +        depends on HAS_ITS
> > > > +        int "Maximum bits for GICv3 host LPIs (14-32)"
> > > > +        range 14 32
> > > > +        default "20"
> > > > +        help
> > > > +          Specifies the maximum number of LPIs (in bits) Xen should
> > > > take
> > > > +          care of. The host ITS may provide support for a very large
> > > > number
> > > > +          of supported LPIs, for all of which we may not want to
> > > > allocate
> > > > +          memory, so this number here allows to limit this.
> > > > +          Xen itself does not know how many LPIs domains will ever need
> > > > +          beforehand.
> > > > +          This can be overridden on the command line with the
> > > > max_lpi_bits
> > > > +          parameter.
> > > 
> > > I continue to disagree on this Kconfig option. There is no sensible
> > > default value and I don't see how a distribution will be able to pick-up
> > > one value here.
> > > 
> > > If the number of LPIs have to be restricted, this should be done via the
> > > command line or a per-platform option.
> > 
> > So are you opting for taking the hardware provided value, unless there
> > is a command line option or a per-platform limit?
> > 
> > Please keep in mind that the situation here is different from the device
> > table:
> > - There is no indirect table option for the property and pending table.
> >   Any redistributor supporting 32 bits worth of LPIs would lead to a
> >   4GB property table and 512MB pending table allocation.
> > - An OS like Linux can make sensible assumptions about the number of
> >   LPIs needed and only allocate as much LPIs as required. Linux for
> >   instance uses at most 65536. Xen cannot easily make this decision.
> >   So we would need to go as high as possible, but not too high to not
> >   waste memory. I see different tradeoffs here between a distribution
> >   targeting servers or another one aiming at some embedded devices, for
> >   instance. So I would expect exactly this decision to be covered by a
> >   Kconfig option.
> 
> Hence why a parameter on the command line is the better place for that. The
> decision is left to the user.
> 
> > > I have already made my point on previous e-mails so I am not going to
> > > argue more.
> > 
> > So as I mentioned before, I am happy to loose the Kconfig option, but
> > then we need some sensible default value. In our case we could be cheeky
> > here for now and just use the Linux value, because a Linux Dom0 would be
> > the only user. But that doesn't sound very future proof, though this may
> > not matter for 4.9.
> 
> I don't think we need a sensible default value and IHMO there is none. I would
> left the user to decide the exact number.

In that case, the command line parameter becomes mandatory: we need to
force the user to specify it as we do for dom0_mem today.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel