public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Steve Wahl <steve.wahl@hpe.com>, Joerg Roedel <jroedel@suse.de>,
	Kyung Min Park <kyung.min.park@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Will Deacon <will@kernel.org>,
	iommu@lists.linux-foundation.org, "Tian,
	Kevin" <kevin.tian@intel.com>
Cc: Mike Travis <mike.travis@hpe.com>,
	Dimitri Sivanich <sivanich@hpe.com>,
	Russ Anderson <russ.anderson@hpe.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED
Date: Fri, 6 May 2022 13:57:00 +0800	[thread overview]
Message-ID: <e2afd89c-b1cf-9fde-4ce2-4be3c1fdaf07@linux.intel.com> (raw)
In-Reply-To: <20220505194658.246121-1-steve.wahl@hpe.com>

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.

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

Best regards,
baolu

  reply	other threads:[~2022-05-06  5:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 19:46 [PATCH] iommu/vt-d: Increase DMAR_UNITS_SUPPORTED Steve Wahl
2022-05-06  5:57 ` Baolu Lu [this message]
2022-05-06  6:49   ` Tian, Kevin
2022-05-06  7:10     ` Rodel, Jorg
2022-05-06  7:47       ` Tian, Kevin
2022-05-06  7:16     ` David Woodhouse
2022-05-06  8:12       ` Tian, Kevin
2022-05-06 15:26         ` Steve Wahl
2022-05-10  1:16           ` Tian, Kevin
2022-05-10 19:06             ` Steve Wahl
2022-05-11  3:36               ` Tian, Kevin
2022-05-12 15:13 ` [PATCH v2] iommu/vt-d: Make DMAR_UNITS_SUPPORTED a config setting Steve Wahl
2022-05-12 23:12   ` Steve Wahl
2022-05-13  2:09     ` Baolu Lu
2022-05-18 19:58       ` Steve Wahl
2022-05-23  6:43         ` Tian, Kevin
2022-06-13 20:38   ` Jerry Snitselaar
2022-06-14  1:33     ` Baolu Lu
2022-06-13 20:57   ` Jerry Snitselaar
2022-06-14  1:36     ` Baolu Lu
2022-06-14  1:44       ` Jerry Snitselaar
2022-06-14  1:51         ` Baolu Lu
2022-06-14  1:54           ` Jerry Snitselaar
2022-06-14  2:21             ` Baolu Lu
2022-06-14 16:45               ` Steve Wahl
2022-06-14 19:01                 ` Jerry Snitselaar
2022-06-14 21:12                   ` Steve Wahl
2022-06-15  1:38                     ` Baolu Lu
2022-06-15 15:02                       ` Steve Wahl
2022-06-15 18:36                       ` [PATCH v3] " Steve Wahl
2022-06-15 18:39                         ` Jerry Snitselaar
2022-06-22 14:52                         ` Baolu Lu
2022-06-22 15:05                           ` Jerry Snitselaar
2022-06-22 15:11                             ` Steve Wahl
2022-06-23  2:29                             ` Baolu Lu
2022-06-23  2:51                               ` Jerry Snitselaar
2022-06-23  3:38                                 ` Baolu Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2afd89c-b1cf-9fde-4ce2-4be3c1fdaf07@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jroedel@suse.de \
    --cc=kevin.tian@intel.com \
    --cc=kyung.min.park@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.travis@hpe.com \
    --cc=russ.anderson@hpe.com \
    --cc=sivanich@hpe.com \
    --cc=steve.wahl@hpe.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox