From: David Box <david.e.box@linux.intel.com>
To: ilpo.jarvinen@linux.intel.com, linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, rodrigo.vivi@intel.com,
michael.j.ruhl@intel.com, ayaz.siddiqui@intel.com,
syed.abdul.muqthyar.ahmed@intel.com,
intel-xe@lists.freedesktop.org, hansg@kernel.org
Subject: Re: [PATCH v3 1/1] platform/x86/intel/pmt: Notify userspace when crashlogs complete
Date: Fri, 13 Nov 2026 13:20:55 -0800 [thread overview]
Message-ID: <179460474975.2604806.7772916319418845665@linux.intel.com> (raw)
In-Reply-To: <c265bd093c23d96417cb5c6504938c90adc36ac9.1794444671.git.david.e.box@linux.intel.com>
Sashiko's report [1] is right, and the underlying problem isn't one the
crashlog driver can fix on its own. Please hold off on this version.
The problem
On BMG and CRI, PMT features share one MMIO window, and a SoC remapper
index selects which region it shows. That is why PMT has callbacks: the
parent switches the window and performs the access under its lock
(xe->pmt.lock). On CRI the read_reg()/write_reg() callbacks cover the
discovery status and control areas.
For CRI, xe also holds pmt.lock across intel_vsec_register() with the
window parked on discovery, because the PMT drivers read their
discovery headers directly rather than through a callback. But a PMT
driver's probe also needs its own regions: crashlog reads its status
through read_reg(), which must take pmt.lock to switch the window. v2
deadlocked on exactly that, and v3 hit the same lock through an ABBA
with control_mutex (what Sashiko found). Remove has the same problem,
and the lock doesn't protect a PMT driver loaded after registration.
What it takes to fix
1. Document the contract in include/linux/intel_vsec.h: callbacks may
be called from the client's probe and remove, so a parent must not
hold a lock its callbacks take across intel_vsec_register() or
device removal. I'll send that patch.
2. Have xe switch the window only at the time of each access, as
xe_pmt_telem_read() already does, and stop holding pmt.lock across
registration. The only thing that requires holding it today is the
PMT drivers' direct discovery-header reads. Since the headers are
static, xe can copy the discovery tables under the lock before
registering and pass the copy in, and the PMT drivers can decode
from it. Live status and control stay on read_reg()/write_reg().
I'll can do the PMT side.
3. Then v4 of this patch returns to the simpler v2 design: check for a
completed crashlog directly in probe, with no work item. The other
v3 fixes stay.
Michael, does switching the window only at access time work for CRI,
and are there other direct reads of the window I'm missing? Ilpo, are
you OK with the documented contract and with the PMT drivers decoding
discovery headers from a copy the parent provides?
[1] https://lore.kernel.org/all/sashiko-outbox-210176@kernel.org/
David
prev parent reply other threads:[~2026-11-13 21:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 2:08 [PATCH v3 0/1] " David E. Box
2026-11-12 2:08 ` [PATCH v3 1/1] " David E. Box
2026-11-13 21:20 ` David Box [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=179460474975.2604806.7772916319418845665@linux.intel.com \
--to=david.e.box@linux.intel.com \
--cc=ayaz.siddiqui@intel.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.j.ruhl@intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=syed.abdul.muqthyar.ahmed@intel.com \
/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
all inboxes | Powered by JetHome®