RE: [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED

[Tian, Kevin]

> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Friday, May 6, 2022 1:57 PM
> 
> On 2022/5/6 03:46, Steve Wahl wrote:
> > Increase DMAR_UNITS_SUPPORTED to support 64 sockets with 10 DMAR
> units
> > each, for a total of 640.
> >
> > If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously
> set
> > to MAX_IO_APICS, or 128), it causes these messages: "DMAR: Failed to
> > allocate seq_id", "DMAR: Parse DMAR table failure.", and "x2apic: IRQ
> > remapping doesn't support X2APIC mode x2apic disabled"; and the system
> > fails to boot.
> >
> > Signed-off-by: Steve Wahl <steve.wahl@xxxxxxx>
> > Reviewed-by: Mike Travis <mike.travis@xxxxxxx>
> > ---
> >
> > Note that we could not find a reason for connecting
> > DMAR_UNITS_SUPPORTED to MAX_IO_APICS as was done previously.
> Perhaps
> > it seemed like the two would continue to match on earlier processors.
> > There doesn't appear to be kernel code that assumes that the value of
> > one is related to the other.
> 
> +Kevin
> 
> This maximum value was introduced by below commit. And I don't see any
> hardware/software restrictions that we can't enlarge it after ten years.

I don't see a rationale either, but...

> 
> commit 1b198bb04ad72669d4bd6575fc9945ed595bfee0
> Author: Mike Travis <travis@xxxxxxx>
> Date:   Mon Mar 5 15:05:16 2012 -0800
> 
>      x86/iommu/intel: Increase the number of iommus supported to
> MAX_IO_APICS
> 
>      The number of IOMMUs supported should be the same as the number
>      of IO APICS.  This limit comes into play when the IOMMUs are
>      identity mapped, thus the number of possible IOMMUs in the
>      "static identity" (si) domain should be this same number.
> [...]
> 
> >
> >   include/linux/dmar.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/dmar.h b/include/linux/dmar.h
> > index 45e903d84733..9d4867b8f42e 100644
> > --- a/include/linux/dmar.h
> > +++ b/include/linux/dmar.h
> > @@ -19,7 +19,7 @@
> >   struct acpi_dmar_header;
> >
> >   #ifdef	CONFIG_X86
> > -# define	DMAR_UNITS_SUPPORTED	MAX_IO_APICS
> > +# define	DMAR_UNITS_SUPPORTED	640
> >   #else
> >   # define	DMAR_UNITS_SUPPORTED	64
> >   #endif
> 

... is it necessary to permanently do 10x increase which wastes memory
on most platforms which won't have such need.

Does it make more sense to have a configurable approach similar to
CONFIG_NR_CPUS? or even better can we just replace those static
arrays with dynamic allocation so removing this restriction
completely?

another nit: dmar is intel specific thus CONFIG_X86 is always true.

Thanks
Kevin