lkml.org 
[lkml]   [2022]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED
    Date
    > 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
    \
     
     \ /
      Last update: 2022-05-06 08:52    [W:3.707 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site