[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 02/27] ARM: GICv3: allocate LPI pending and property table
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |