Re: [PATCH v3] iommu/vt-d: Make DMAR_UNITS_SUPPORTED a config setting

From: Baolu Lu
Date: Wed Jun 22 2022 - 22:29:46 EST


On 2022/6/22 23:05, Jerry Snitselaar wrote:
On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx> wrote:
On 2022/6/16 02:36, Steve Wahl wrote:
To support up to 64 sockets with 10 DMAR units each (640), make the
value of DMAR_UNITS_SUPPORTED adjustable by a config variable,
CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when MAXSMP is
set.

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 properly.

Signed-off-by: Steve Wahl<steve.wahl@xxxxxxx>
Reviewed-by: Kevin Tian<kevin.tian@xxxxxxxxx>
---

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.

v2: Make this value a config option, rather than a fixed constant. The default
values should match previous configuration except in the MAXSMP case. Keeping the
value at a power of two was requested by Kevin Tian.

v3: Make the config option dependent upon DMAR_TABLE, as it is not used without this.

drivers/iommu/intel/Kconfig | 7 +++++++
include/linux/dmar.h | 6 +-----
2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig
index 39a06d245f12..07aaebcb581d 100644
--- a/drivers/iommu/intel/Kconfig
+++ b/drivers/iommu/intel/Kconfig
@@ -9,6 +9,13 @@ config DMAR_PERF
config DMAR_DEBUG
bool

+config DMAR_UNITS_SUPPORTED
+ int "Number of DMA Remapping Units supported"
+ depends on DMAR_TABLE
+ default 1024 if MAXSMP
+ default 128 if X86_64
+ default 64
With this patch applied, the IOMMU configuration looks like:

[*] AMD IOMMU support
<M> AMD IOMMU Version 2 driver
[*] Enable AMD IOMMU internals in DebugFS
(1024) Number of DMA Remapping Units supported <<<< NEW
[*] Support for Intel IOMMU using DMA Remapping Devices
[*] Export Intel IOMMU internals in Debugfs
[*] Support for Shared Virtual Memory with Intel IOMMU
[*] Enable Intel DMA Remapping Devices by default
[*] Enable Intel IOMMU scalable mode by default
[*] Support for Interrupt Remapping
[*] OMAP IOMMU Support
[*] Export OMAP IOMMU internals in DebugFS
[*] Rockchip IOMMU Support

The NEW item looks confusing. It looks to be a generic configurable
value though it's actually Intel DMAR specific. Any thoughts?

Best regards,
baolu

Would moving it under INTEL_IOMMU at least have it show up below
"Support for Intel IOMMU using DMA Remapping Devices"? I'm not sure it
can be better than that, because IRQ_REMAP selects DMAR_TABLE, so we
can't stick it in the if INTEL_IOMMU section.

It's more reasonable to move it under INTEL_IOMMU, but the trouble is
that this also stands even if INTEL_IOMMU is not configured.

The real problem here is that the iommu sequence ID overflows if
DMAR_UNITS_SUPPORTED is not big enough. This is purely a software
implementation issue, I am not sure whether user opt-in when building a
kernel package could help a lot here.

If we can't find a better way, can we just step back?

Best regards,
baolu