Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED | Date | Fri, 6 May 2022 06:49:43 +0000 |
| |
> From: Baolu Lu <baolu.lu@linux.intel.com> > 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@hpe.com> > > Reviewed-by: Mike Travis <mike.travis@hpe.com> > > --- > > > > 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@sgi.com> > 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
| |