[PATCH AUTOSEL 6.18-6.12] iommu/amd: Fix missing CMD_COMPLETE_PPR response for invalid PPR requests

[Sasha Levin <sashal@kernel.org>]

From: Vasant Hegde <vasant.hegde@amd.com>

[ Upstream commit bc1f5ec826bfa510e7138e2be5aad23907850874 ]

The AMD IOMMU spec, requires the host to respond with a CMD_COMPLETE_PPR
command when an EVENT_TYPE_INV_PPR_REQ event is received with the RX bit
cleared. This response was missing in the current implementation, leaving
invalid PPR requests unacknowledged.

Introduce amd_iommu_report_ppr_err() to handle EVENT_TYPE_INV_PPR_REQ
events. The new function logs the invalid PPR request and when the RX
bit is cleared, sends CMD_COMPLETE_PPR response.

Reported-by: Gaultier Delbarre <Gaultier.Delbarre@amd.com>
Co-developed-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Ankit Soni <Ankit.Soni@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: the INV_PPR_REQ path is in this 6.12 tree, the
completion helper already exists, and the fix is a small spec-compliance
change to stop PRI stalls.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[iommu/amd] [Fix] missing CMD_COMPLETE_PPR response for
invalid PPR requests.** The subject is an explicit bug fix in the AMD
IOMMU driver: invalid PPR (Page Request) events were logged but not
acknowledged to hardware.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Reported-by:** Gaultier Delbarre (AMD) — real hardware/spec issue
  found inside AMD, not a theoretical cleanup.
- **Co-developed-by / Signed-off-by:** Wei Huang (AMD), Vasant Hegde
  (AMD IOMMU maintainer/author).
- **Reviewed-by:** Ankit Soni (AMD).
- **Signed-off-by:** Joerg Roedel (IOMMU maintainer).
- **No Fixes: tag** (expected for this review pipeline).
- **No Cc: stable** (expected).
- **No syzbot, Link, Tested-by, or Acked-by.**
- Ignore any pipeline-added Sasha Levin SOB / Upstream commit markers.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** AMD IOMMU spec requires the host to issue `CMD_COMPLETE_PPR`
  when an `EVENT_TYPE_INV_PPR_REQ` event arrives with the RX bit
  **cleared**. The driver only printed `INVALID_PPR_REQUEST` and
  returned.
- **Symptom:** Invalid PPR/PRI requests stay unacknowledged. The device
  keeps the outstanding page-request slot; further PRI traffic can stall
  (DMA/GPU/SVA hang), rather than a kernel oops.
- **Root cause:** Event-log handler treated INV_PPR_REQ as log-only; the
  completion path used for valid PPR (`amd_iommu_complete_ppr()`) was
  never invoked.
- **Fix:** New `amd_iommu_report_ppr_err()` logs the event and, if RX=0,
  sends `CMD_COMPLETE_PPR` with `IOMMU_PAGE_RESP_FAILURE`.
- **Version info in message:** none.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: **Not a hidden fix.** The subject and body state a spec-mandated
missing hardware response. This is a protocol/hang fix, not a style
cleanup.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**

Record:
- `drivers/iommu/amd/amd_iommu_types.h`: +1 (`EVENT_FLAG_PPR_RX 0x001`).
- `drivers/iommu/amd/iommu.c`: ~+33/-6. New
  `amd_iommu_report_ppr_err()`; `iommu_print_event()` INV_PPR_REQ case
  now calls it; unused local `tag` removed.
- **Scope:** single-driver surgical fix. ~38 lines net. No API/ABI
  change.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** `iommu_print_event()` on type 0x9 extracted PASID/tag,
  `dev_err()`, break. No IOMMU command.
- **After:** same log, then if `!(flags & EVENT_FLAG_PPR_RX)` look up
  the PCI device, check IOMMU private data, call existing
  `amd_iommu_complete_ppr(..., IOMMU_PAGE_RESP_FAILURE, tag)`.
- **Path:** threaded IRQ event-log poll (`amd_iommu_int_thread_evtlog` →
  `iommu_poll_events` → `iommu_print_event`), not a syscall hot path.
  Error/exception path for invalid hardware page requests.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record: **Hardware protocol / hang (logic/correctness).** Missing
command on an exception event. Analogous to Intel VT-d
`handle_bad_prq_event()`, which already submits a page-group response
for invalid PRQ. Not UAF/leak/race/overflow.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- **Obviously correct** for the common case: RX=0 → complete with
  FAILURE using the same helper as `ppr.c` already uses for “nobody
  cared” PPR entries.
- **Minimal:** one flag, one helper, one call-site change.
- **Regression risk: low.** Patterns match existing event/PPR handling
  (`pci_get_domain_bus_and_slot` + `pci_dev_put` already used from
  `amd_iommu_report_page_fault()` in this same function).
  `iommu_queue_command()` takes `iommu->lock` with
  `raw_spin_lock_irqsave`; `iommu_print_event()` does not hold that
  lock.
- **Known incompleteness (accepted in the committed form):** if
  `pci_get_domain_bus_and_slot()` fails or there is no IOMMU priv, it
  still returns without COMPLETE_PPR. Ankit Soni raised that on list;
  the committed diff still has those early returns, and Ankit still
  Reviewed-by. Those are devices not in the PCI tree / not bound — the
  PRI-using devices this matters for have both.
- **Follow-up in the same series (not this commit):** patch 4 rate-
  limits the log; patch 5 fixes GN derivation (`pri_tlp` vs v2 page-
  table). This commit uses existing `amd_iommu_complete_ppr()` (GN from
  `pri_tlp`), which is already how every COMPLETE_PPR in **this** tree
  is built. Not a new regression vs current 6.12 behavior.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- INV_PPR_REQ case introduced in **e7f63ffc1bf19** (“iommu/amd: Update
  logging information for new event type”, 2018-05-01, Gary R Hook) —
  log-only from the start.
- PASID extraction: 470eb3b31134ad (Suravee, 2019).
- Log format: later Vasant Hegde updates (b36a5b0f1cedbb / pci_seg).
- Buggy behavior (log, no COMPLETE_PPR) has been in-tree for years,
  including this 6.12 checkout.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: **No Fixes: tag.** The missing response became operationally
important once PRI/PPR completion existed: **978d626b8f1a2**
(“iommu/amd: Add IO page fault notifier handler”, Wei Huang, 2024-04-18)
added `amd_iommu_complete_ppr()` and PPR log handling. That commit **is
an ancestor of HEAD**.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record:
- This commit is **patch 3/5** of “iommu/amd: PRI related cleanup and
  fixes” (Vasant Hegde, 2026-07-27).
  1. Device ID in invalid PASID log — **already in this tree**
     (`5a5cd58b1533e`).
  2. `PPR_TAG_LAST_PAGE()` macro — cleanup; **not required** for this
     patch.
  3. **This fix** — missing COMPLETE_PPR.
  4. Rate-limit INVALID_PPR_REQUEST — depends on 3; current 6.12 already
     logs unbounded `dev_err` here, so 3 alone is not a log-flood
     regression.
  5. GN bit in COMPLETE_PPR — separate correctness fix; refactors
     `amd_iommu_complete_ppr()`.
- Recent `iommu.c` churn is attach/flush locking, not this event case.
  **Standalone for the bug it fixes.**

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Vasant Hegde is the AMD IOMMU driver author on this tree (many
`drivers/iommu/amd/` commits). Wei Huang added the 2024 IOPF/PPR
notifier. This is a maintainer-area fix, not a drive-by.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: **Can apply standalone on this tree.** Required symbols all
exist:
- `amd_iommu_complete_ppr()` (`iommu.c` ~1827, declared in
  `amd_iommu.h`)
- `PPR_PASID()`, `IOMMU_PAGE_RESP_FAILURE`,
  `pci_get_domain_bus_and_slot`, `dev_iommu_priv_get`, `iommu->pci_seg`
- `EVENT_TYPE_INV_PPR_REQ` case already present
- Patches 2/4/5 not required for this change to compile or to send a
  completion.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- Series: [PATCH 0/5] iommu/amd: PRI related cleanup and fixes, Vasant
  Hegde, 2026-07-27.
- Patch 3: https://ratatoskr.run/linux-iommu/2026/07/17321958
- Cover: https://ratatoskr.run/linux-iommu/2026/07/17321955
- Review: https://ratatoskr.run/linux-iommu/2026/07/17327932 (Ankit
  Soni, 2026-07-28): suggested issuing COMPLETE_PPR even when
  `pdev`/priv is missing, via
  `build_complete_ppr()`/`iommu_queue_command()`. **No NAK.** Committed
  code matches v1 (early returns kept) and carries Ankit’s Reviewed-by.
- **UNVERIFIED:** `b4 dig -c` needs a SHA not in this checkout. `b4
  mbox` of msgid `26cfa307-6c33-41f9-a7a0-fbf202b38a00@amd.com` returned
  an unrelated IRT-cache thread. lore.kernel.org search URLs returned
  **403**. No evidence of a later v2 that replaced this diff.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record: Recipients/maintainers on the series include Joerg Roedel (SOB
on the commit), Ankit Soni (Reviewed-by), Wei Huang (co-developer).
Appropriate AMD IOMMU reviewers.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: Reporter is AMD (Gaultier Delbarre). No public syzbot/bugzilla
link. This is spec non-compliance observed on AMD hardware/firmware, not
a fuzzer crash.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: 5-patch PRI series. Patch 1 already backported here. 2 is
cosmetic. 3 is the hang/protocol fix. 4 is log-rate-limit on top of 3. 5
is GN-bit correctness for all COMPLETE_PPR, plus using event-flag GN on
this new path. **This commit is self-contained;** 5 is a nice follow-up,
not a hard apply dependency.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: **UNVERIFIED** — lore.kernel.org/stable returned 403. No local
`git log --grep=CMD_COMPLETE_PPR` hits in this tree.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**

Record: Added `amd_iommu_report_ppr_err()`. Modified
`iommu_print_event()`. Calls existing `amd_iommu_complete_ppr()`.

**Step 5.2: TRACE CALLERS**

Record:
- `iommu_print_event()` ← `iommu_poll_events()` ←
  `amd_iommu_int_thread_evtlog()` / `amd_iommu_int_thread()` (threaded
  IRQ).
- `amd_iommu_complete_ppr()` already called from
  `iommu_call_iopf_notifier()` and `amd_iommu_page_response()` in
  `ppr.c` (same IRQ-thread class for PPR log).

**Step 5.3: TRACE CALLEES**

Record: `PPR_PASID()`, `pci_get_domain_bus_and_slot()`,
`dev_iommu_priv_get()`, `amd_iommu_complete_ppr()` →
`build_complete_ppr()` + `iommu_queue_command()` (command buffer, may
`udelay` under `iommu->lock` on full buffer — existing behavior).

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: **Reachable in production** on AMD IOMMU hardware with PPR
(Guest Translation + PPR + EPHSUP: `amd_iommu_gt_ppr_supported()`). PPR
log is enabled in `enable_iommus_ppr()`. PRI is enabled on SVA-capable
domain attach (`pdev_enable_caps()`). Userspace/devices that use
SVA/PASID/PRI (AMD GPU SVM, some VFIO) can generate PPR; invalid ones
produce INV_PPR_REQ in the event log. Not a syscall bug; a device
DMA/PRI stall.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: `ppr.c` already completes invalid/unhandled PPR log entries with
`IOMMU_PAGE_RESP_FAILURE`. Intel `handle_bad_prq_event()` always
responds to invalid PRQ when LPIG is set. This patch closes the AMD
event-log gap for the same class of bug.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** Local tree is **6.12.111** (`p-6.12-3-gc504cf0baa3d8`,
Makefile VERSION/PATCHLEVEL/SUBLEVEL 6/12/111).

```973:979:drivers/iommu/amd/iommu.c
        case EVENT_TYPE_INV_PPR_REQ:
                pasid = PPR_PASID(*((u64 *)__evt));
                tag = event[1] & 0x03FF;
                dev_err(dev, "Event logged [INVALID_PPR_REQUEST ...
                break;
```

No `EVENT_FLAG_PPR_RX`, no `amd_iommu_report_ppr_err()`. Bug introduced
as log-only in 2018; completion helper present since 978d626b8f1a2 (in
this tree).

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Expected apply: clean or trivial context.** 6.12
`iommu_print_event()` lacks a later `ctrl = readq(MMIO_CONTROL_OFFSET)`
local that appears in the mainline hunk context; the INV_PPR_REQ case,
`report_page_fault` insertion point, and `EVENT_FLAG_I` site match. No
conflicting local change to this switch arm.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: No existing COMPLETE_PPR on INV_PPR_REQ. Related:
`5a5cd58b1533e` (series patch 1, log-only), `1de4443f85e44` (pci_dev_put
after PPR faults). **This specific bug is unfixed here.**

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: **drivers/iommu/amd** — **IMPORTANT** (not core mm/VFS). AMD
IOMMU is default DMA isolation on AMD x86; PRI/PPR is a subset
(SVA/IOPF), but a hung PRI-capable device (GPU) is user-visible.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Actively maintained in 6.12 (flush, attach locking, SNP log
sizes, PPR). Mature driver; this event type is old. Fix is not for
brand-new code missing from 6.12.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Platform/config-specific:** AMD IOMMU + PPR/PRI-capable
devices (SVA/PASID). Not every AMD desktop, but real 6.12 users
(ROCm/KFD SVM, IOMMU page-fault devices).

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Hardware logs INV_PPR_REQ (invalid PRI/PPR). RX=0 means software
**must** complete. Trigger is device-generated, not a userspace syscall.
Unprivileged code on an SVA-bound device can cause invalid page
requests. Timing: not a race; missing response every time RX=0.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record: **Device/PRI hang (HIGH), not a kernel panic.** Unacked PRI
consumes outstanding page-request slots (PRI enable uses 32 outstanding
in `pdev_enable_cap_pri()`). Device DMA can stall; GPU/compute jobs
hang. Matches stable-rules “hang” / hardware protocol failure. Reporter
is AMD — they saw it.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit: high** for AMD PRI/SVA users (prevents stuck page-request
  state).
- **Risk: low** (~30 lines, existing helper, same IRQ-thread context as
  PPR completion, no lock-order novelty vs `report_page_fault`).
- **Ratio:** favorable. Worst extra load is queuing COMPLETE_PPR under a
  PPR flood; spec requires that, and command-buffer timeout already
  exists.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real spec bug: missing `CMD_COMPLETE_PPR` for INV_PPR_REQ with RX=0.
- User-visible hang (PRI/DMA stall), reported by AMD.
- Buggy log-only path exists in this 6.12 tree; completion helper
  already here.
- Small, obviously correct, uses existing `amd_iommu_complete_ppr()`.
- Reviewed by AMD; SOB from Joerg Roedel.
- Intel already answers invalid PRQ the same way.
- No new APIs/features.

**AGAINST:**
- Not a kernel oops/UAF; only PRI-capable AMD devices.
- Series follow-ups 4 (ratelimit) and 5 (GN bit) are not in this commit;
  5 says `pri_tlp` is the wrong GN source — but that is **already** how
  6.12 completes all PPRs.
- Corner-case still skips completion without `pdev`/priv.
- No Fixes:/Cc: stable (not a negative per pipeline rules).

**UNRESOLVED:**
- Exact mainline SHA (`b4 dig -c` not possible without it).
- Stable-list discussion (lore 403).
- Whether a v2 addressed Ankit’s always-complete suggestion (committed
  diff matches v1).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — spec-aligned; AMD-
   developed/reviewed; Joerg SOB. (Tested-by not in message; author +
   reviewer are the hardware vendor.)
2. Fixes a real bug that affects users? **PASS** — unacked invalid PPR;
   Reported-by AMD.
3. Important issue (crash, security, corruption, deadlock)? **PASS** —
   hang / hardware protocol stall (HIGH), not cosmetic.
4. Small and contained? **PASS** — ~30 lines, two files, one driver.
5. No new features or APIs? **PASS** — uses existing complete-PPR
   command.
6. Can apply to the local tree? **PASS** — buggy code and helpers
   present; apply should be clean or trivial context.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: Not a device-ID/quirk/DT/build/doc exception. Qualifies as a
**normal hang/protocol bug fix**.

**Step 9.4: MAKE YOUR DECISION**

This should be backported to **this** 6.12.y tree. The INV_PPR_REQ
handler has never sent COMPLETE_PPR; 6.12 already has PRI/PPR completion
for the PPR log. The patch is small, uses that helper, and prevents
device-side PRI stalls on AMD IOMMU.

The problem is a missing hardware response, not a new feature. Stable
users with AMD IOMMU + PRI/SVA can hang outstanding page requests; the
fix is ~30 lines and matches code already used from `ppr.c`. Patch 5 (GN
bit) is a separate improvement already latent in 6.12’s `pri_tlp` usage
and is not required for this commit to help.

Verification:
- [Phase 1] Parsed tags: Reported-by Gaultier Delbarre (AMD); Co-
  developed-by Wei Huang; SOB Vasant Hegde + Joerg Roedel; Reviewed-by
  Ankit Soni; no Fixes/Cc:stable/syzbot.
- [Phase 2] Diff: +EVENT_FLAG_PPR_RX; new amd_iommu_report_ppr_err();
  INV_PPR_REQ calls complete_ppr on RX=0; ~33/-6 lines.
- [Phase 3] git blame 973-979 iommu.c: e7f63ffc1bf19 (2018) introduced
  log-only INV_PPR_REQ.
- [Phase 3] 978d626b8f1a2 is ancestor of HEAD (`git merge-base --is-
  ancestor` succeeded); amd_iommu_complete_ppr exists at iommu.c:1827.
- [Phase 3] git log --oneline --grep=CMD_COMPLETE_PPR --
  drivers/iommu/amd/: empty (fix not in this tree).
- [Phase 3] Series patch 1 already present: 5a5cd58b1533e.
- [Phase 4] Ratatoskr: series 0/5 17321955, patch 3 17321958, Ankit
  review 17327932 (corner case, no NAK).
- [Phase 4] b4 dig -c: **UNVERIFIED** (SHA not in tree). b4 mbox of
  26cfa307-… pulled the wrong thread.
- [Phase 4] lore.kernel.org and lore stable search: **UNVERIFIED** (HTTP
  403).
- [Phase 5] Callers: amd_iommu_int_thread_evtlog → iommu_poll_events →
  iommu_print_event (threaded IRQ). complete_ppr already used from ppr.c
  in the PPR IRQ thread.
- [Phase 5] Intel analog: handle_bad_prq_event() in
  drivers/iommu/intel/prq.c submits QI page-group response.
- [Phase 6] git describe HEAD: p-6.12-3-gc504cf0baa3d8; make
  kernelversion: 6.12.111; buggy INV_PPR_REQ case present;
  EVENT_FLAG_PPR_RX absent.
- [Phase 6] 6.12 iommu_print_event lacks later `ctrl` MMIO read;
  INV_PPR_REQ hunk still matches.
- [Phase 7] Subsystem drivers/iommu/amd, IMPORTANT, actively maintained.
- [Phase 8] Failure mode: unacked PRI → device hang; severity HIGH;
  trigger AMD PPR/PRI hardware.
- UNVERIFIED: mainline SHA; v2 of series; stable@ discussion.

**YES**

 drivers/iommu/amd/amd_iommu_types.h |  1 +
 drivers/iommu/amd/iommu.c           | 38 ++++++++++++++++++++++++-----
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
index dee077bd149b7..5f43a0fcdd1e3 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -158,6 +158,7 @@
 #define EVENT_FLAGS_SHIFT	0x10
 #define EVENT_FLAG_RW		0x020
 #define EVENT_FLAG_I		0x008
+#define EVENT_FLAG_PPR_RX	0x001
 
 /* feature control bits */
 #define CONTROL_IOMMU_EN	0
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index e64e6da08a5f7..49587eafc0a8f 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -883,10 +883,40 @@ static void amd_iommu_report_page_fault(struct amd_iommu *iommu,
 		pci_dev_put(pdev);
 }
 
+static void amd_iommu_report_ppr_err(struct amd_iommu *iommu, volatile u32 *event,
+				     u16 devid, u64 address, int flags)
+{
+	struct pci_dev *pdev;
+	struct device *dev = iommu->iommu.dev;
+	u32 pasid = PPR_PASID(*((u64 *)event));
+	int tag = event[1] & 0x03FF;
+
+	dev_err(dev, "Event logged [INVALID_PPR_REQUEST device=%04x:%02x:%02x.%x pasid=0x%05x address=0x%llx flags=0x%04x tag=0x%03x]\n",
+		iommu->pci_seg->id, PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
+		pasid, address, flags, tag);
+
+	/* Skip COMPLETE_PPR_REQUEST response if RX=1 */
+	if (flags & EVENT_FLAG_PPR_RX)
+		return;
+
+	pdev = pci_get_domain_bus_and_slot(iommu->pci_seg->id, PCI_BUS_NUM(devid),
+					   devid & 0xff);
+	if (!pdev)
+		return;
+
+	if (!dev_iommu_priv_get(&pdev->dev)) {
+		pci_dev_put(pdev);
+		return;
+	}
+
+	amd_iommu_complete_ppr(&pdev->dev, pasid, IOMMU_PAGE_RESP_FAILURE, tag);
+	pci_dev_put(pdev);
+}
+
 static void iommu_print_event(struct amd_iommu *iommu, void *__evt)
 {
 	struct device *dev = iommu->iommu.dev;
-	int type, devid, flags, tag;
+	int type, devid, flags;
 	volatile u32 *event = __evt;
 	int count = 0;
 	u64 address, ctrl;
@@ -960,11 +990,7 @@ static void iommu_print_event(struct amd_iommu *iommu, void *__evt)
 		amd_iommu_report_rmp_hw_error(iommu, event);
 		break;
 	case EVENT_TYPE_INV_PPR_REQ:
-		pasid = PPR_PASID(*((u64 *)__evt));
-		tag = event[1] & 0x03FF;
-		dev_err(dev, "Event logged [INVALID_PPR_REQUEST device=%04x:%02x:%02x.%x pasid=0x%05x address=0x%llx flags=0x%04x tag=0x%03x]\n",
-			iommu->pci_seg->id, PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
-			pasid, address, flags, tag);
+		amd_iommu_report_ppr_err(iommu, event, devid, address, flags);
 		break;
 	default:
 		dev_err(dev, "Event logged [UNKNOWN event[0]=0x%08x event[1]=0x%08x event[2]=0x%08x event[3]=0x%08x\n",
-- 
2.53.0