linux-kernel - RE: [PATCH] iommu/vt-d: Increase DMAR_UNITS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276F4D5F8AD33293233B9AB8CC59@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Fri, 6 May 2022 06:49:43 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Baolu Lu <baolu.lu@...ux.intel.com>,
        Steve Wahl <steve.wahl@....com>,
        "Rodel, Jorg" <jroedel@...e.de>,
        Kyung Min Park <kyung.min.park@...el.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Will Deacon <will@...nel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
CC:     Mike Travis <mike.travis@....com>,
        Dimitri Sivanich <sivanich@....com>,
        "Anderson, Russ" <russ.anderson@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED

> From: Baolu Lu <baolu.lu@...ux.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@....com>
> > Reviewed-by: Mike Travis <mike.travis@....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@....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