Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Yigit Oguz <yigitogu@amazon.de>,
	joro@8bytes.org, will@kernel.org, baolu.lu@linux.intel.com,
	dwmw2@infradead.org, suravee.suthikulpanit@amd.com
Cc: jgg@ziepe.ca, nicolinc@nvidia.com, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] iommu: Add PCI vendor:device ID to IOMMU fault logs
Date: Fri, 8 May 2026 11:45:50 +0100	[thread overview]
Message-ID: <b00c0492-e71a-4be6-b95f-ec3b424cc8ac@arm.com> (raw)
In-Reply-To: <20260506150541.60467-1-yigitogu@amazon.de>

On 2026-05-06 4:05 pm, Yigit Oguz wrote:
> IOMMU fault and event logs currently identify devices using only their
> PCI segment/bus/device/function (SSSS:BB:DD.F). While mapping a single
> BDF to a device type is straightforward, doing so at scale across many
> hosts and thousands of fault events requires additional tooling and
> manual cross-referencing. Including the vendor:device ID directly in
> the log line makes each event self-contained and immediately actionable
> without any post-processing.

Sorry, but why are unexpected DMA faults happening "at scale" in the 
first place? If you have so many broken drivers that disambiguating them 
needs help from the kernel, something seems fundamentally wrong with 
that picture. Conversely if these are devices assigned to userspace then 
we should perhaps reconsider their ability to spam up the host kernel 
log at will anyway.

I'm not saying I necessarily have anything against this change in 
particular, but it has a strong smell of effort being spent on the wrong 
thing...

(And even then AFAICS it only really helps in the specific scenario of 
having only one of each type of device, otherwise you're back to still 
needing per-system knowledge of how BDFs map to physical instances to 
know what's what.)

Thanks,
Robin.

> This series adds vendor:device ID (VVVV:DDDD) to IOMMU event logs for
> ARM SMMUv3, Intel VT-d and AMD IOMMU.
> 
> Before:
>    arm-smmu-v3 arm-smmu-v3.0.auto: event: F_TRANSLATION client: 0000:2b:11.6
>      sid: 0x158e ssid: 0x0 iova: 0x280000000000 ipa: 0x0
>    DMAR: [DMA Write NO_PASID] Request device [86:00.0] fault addr 0xe0000000
>      [fault reason 0x05] PTE Write access is not set
>    AMD-Vi: Event logged [IO_PAGE_FAULT device=0000:41:00.0 domain=0x000a
>      address=0xe0000000 flags=0x0020]
> 
> After:
>    arm-smmu-v3 arm-smmu-v3.0.auto: event: F_TRANSLATION client: 0000:2b:11.6 [8086:1533]
>      sid: 0x158e ssid: 0x0 iova: 0x280000000000 ipa: 0x0
>    DMAR: [DMA Write NO_PASID] Request device [0000:86:00.0 8086:1533] fault addr 0xe0000000
>      [fault reason 0x05] PTE Write access is not set
>    AMD-Vi: Event logged [IO_PAGE_FAULT device=0000:41:00.0 8086:1533 domain=0x000a
>      address=0xe0000000 flags=0x0020]
> 
> Patch 1 adds vendor:device ID to ARM SMMUv3 translation fault logs.
> Patch 2 adds PCI segment and vendor:device ID to Intel VT-d DMAR
>          fault logs.
> Patch 3 adds a devid_str helper and vendor:device ID to all AMD IOMMU
>          event log paths.
> 
> Testing:
> Build-tested against mainline Linux (torvalds/master).
> 
> Runtime-tested on a custom downstream branch on ARM SMMUv3, Intel VT-d and
> AMD IOMMU hosts. Translation faults were induced in a virtualized setup
> by removing DMA mappings for an in-use region, causing the assigned device's
> subsequent DMA transactions to hit unmapped IOVAs and produce
> translation fault events. The resulting log lines were verified to
> contain the PCI vendor:device ID on all three platforms.
> 
> Lilit Janpoladyan (1):
>    iommu/arm-smmu-v3: Print PCI vendor:device ID in SMMU translation
>      fault logs
> 
> Yigit Oguz (2):
>    iommu/vt-d: Add PCI segment and vendor:device ID to DMAR fault logs
>    iommu/amd: Add vendor:device ID to AMD IOMMU event logs
> 
>   drivers/iommu/amd/iommu.c                   | 94 +++++++++++++--------
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29 ++++++-
>   drivers/iommu/intel/dmar.c                  | 33 +++++---
>   3 files changed, 104 insertions(+), 52 deletions(-)
> 



      parent reply	other threads:[~2026-05-08 10:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 15:05 [PATCH 0/3] iommu: Add PCI vendor:device ID to IOMMU fault logs Yigit Oguz
2026-05-06 15:05 ` [PATCH 1/3] iommu/arm-smmu-v3: Print PCI vendor:device ID in SMMU translation " Yigit Oguz
2026-05-07 17:01   ` Pranjal Shrivastava
2026-05-06 15:05 ` [PATCH 2/3] iommu/vt-d: Add PCI segment and vendor:device ID to DMAR " Yigit Oguz
2026-05-07 19:21   ` Pranjal Shrivastava
2026-05-06 15:05 ` [PATCH 3/3] iommu/amd: Add vendor:device ID to AMD IOMMU event logs Yigit Oguz
2026-05-07 19:52   ` Pranjal Shrivastava
2026-05-08 10:45 ` Robin Murphy [this message]

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=b00c0492-e71a-4be6-b95f-ec3b424cc8ac@arm.com \
    --to=robin.murphy@arm.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@kernel.org \
    --cc=yigitogu@amazon.de \
    /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