From: Alok Kumar <alkumar@nvidia.com>
To: <dakr@kernel.org>, <acourbot@nvidia.com>, <kvm@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>, <nova-gpu@lists.linux.dev>,
<linux-pci@vger.kernel.org>
Cc: <alex@shazbot.org>, <jgg@nvidia.com>, <yishaih@nvidia.com>,
<skolothumtho@nvidia.com>, <kevin.tian@intel.com>,
<airlied@gmail.com>, <simona@ffwll.ch>, <ojeda@kernel.org>,
<alex.gaynor@gmail.com>, <boqun.feng@gmail.com>,
<gary@garyguo.net>, <bjorn3_gh@protonmail.com>,
<lossin@kernel.org>, <a.hindborg@kernel.org>,
<aliceryhl@google.com>, <tmgross@umich.edu>,
<markus.probst@posteo.de>, <jhubbard@nvidia.com>,
<apopple@nvidia.com>, <joelagnelf@nvidia.com>,
<ecourtney@nvidia.com>, <cjia@nvidia.com>, <smitra@nvidia.com>,
<kjaju@nvidia.com>, <alkumar@nvidia.com>, <ankita@nvidia.com>,
<aniketa@nvidia.com>, <kwankhede@nvidia.com>,
<targupta@nvidia.com>, <linux-kernel@vger.kernel.org>,
<zhiwang@kernel.org>, <zhiw@nvidia.com>, <boqun@kernel.org>,
<daniel.almeida@collabora.com>, <tamird@kernel.org>,
<work@onurozkan.dev>, <jgg@ziepe.ca>, <bhelgaas@google.com>,
<kwilczynski@kernel.org>, <dri-devel@lists.freedesktop.org>,
<peter@colberg.org>, <xinmengs@nvidia.com>
Subject: [PATCH v4 14/32] gpu: nova-core: gsp: wait for GMC completion events
Date: Fri, 6 Nov 2026 11:09:47 +0530 [thread overview]
Message-ID: <8ddb36b189feb56642ed531e5199d3a01e7d7f5e.1793906667.git.alkumar@nvidia.com> (raw)
In-Reply-To: <cover.1793906667.git.alkumar@nvidia.com>
From: Zhi Wang <zhiw@nvidia.com>
GSP plugin shutdown completes through a separate event carrying the
GFID. Releasing the queue guard after sending would let another receiver
consume that completion.
Keep the guard from sending through the matching event and use the
shared Inner receive deadline. Offer GMC events to the completion
predicate, pass unmatched events to the caller's handler, and consume
interleaved responses and RPC messages. Represent completion with a
value and all continuing cases with None.
Propagate callback errors after consuming the current valid element.
Document callback non-reentrancy and that the receive timeout starts
after sending, excluding mutex acquisition and command-queue space
waits.
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Co-developed-by: Alok Kumar <alkumar@nvidia.com>
Signed-off-by: Alok Kumar <alkumar@nvidia.com>
---
Documentation/gpu/nova/core/interrupts.rst | 9 +--
drivers/gpu/nova-core/gsp/cmdq/gmc.rs | 65 ++++++++++++++++++++++
drivers/gpu/nova-core/gsp/fw.rs | 9 +++
3 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/nova/core/interrupts.rst b/Documentation/gpu/nova/core/interrupts.rst
index 7f61e5d6334e..d686d8004aea 100644
--- a/Documentation/gpu/nova/core/interrupts.rst
+++ b/Documentation/gpu/nova/core/interrupts.rst
@@ -582,7 +582,8 @@ command reply or an unsolicited event, and the two differ in the function code.
arrival with its sequence number, function code, and length.
* A GMC message carries a command id in place of a function code. The
``GSP_INIT`` wait and synchronous GMC transactions claim responses with the
- expected command id and sequence number. These waits consume interleaved RPC
+ expected command id and sequence number. A GMC completion-event wait uses its
+ caller's predicate to select an event. These waits consume interleaved RPC
messages as events. Unmatched GMC messages are handled by the wait's callback
or logged and consumed; a queue drain with no waiting caller logs unclaimed
responses and unknown commands at warning level and drops them.
@@ -607,9 +608,9 @@ mutex. Replies and events share one queue and one read pointer, so one lock is
held across the whole drain. A thread waiting for a reply logs each event that
arrives before the reply and keeps waiting. One receive deadline applies to
all messages in the wait. The default timeout is 5 seconds; GMC transactions
-can specify another timeout. For send-and-wait operations the receive deadline
-starts after sending, so it does not bound waiting for the mutex or for
-command-queue space. The thread holds the mutex from sending through receiving,
+and completion-event waits can specify another timeout. For send-and-wait
+operations the receive deadline starts after sending, so it does not bound
+waiting for the mutex or for command-queue space. The thread holds the mutex from sending through receiving,
so no other caller consumes the message it waits for.
With one lock, a drain waits for an in-flight command's receive to finish or
diff --git a/drivers/gpu/nova-core/gsp/cmdq/gmc.rs b/drivers/gpu/nova-core/gsp/cmdq/gmc.rs
index 392143e534f6..c5ae5943c8b8 100644
--- a/drivers/gpu/nova-core/gsp/cmdq/gmc.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq/gmc.rs
@@ -448,6 +448,71 @@ pub(crate) fn send_gmc_and_receive_timeout(
})
}
+ /// Sends an asynchronous GMC command and waits atomically for its event.
+ ///
+ /// The command queue remains locked from the send through the matching
+ /// event, preventing another transaction from consuming its completion.
+ /// GMC events are passed to `predicate`, then to `handler` if the predicate returns false.
+ /// GMC responses are debug-logged and consumed without invoking either callback. Interleaved
+ /// RPC messages are logged as events and consumed.
+ ///
+ /// One receive deadline starts after sending and is not extended by other messages. It does
+ /// not bound waiting for the mutex or for space to send the request.
+ ///
+ /// Both callbacks run with the queue locked and must not reenter this queue or reset it.
+ /// Their second argument is the raw `max_resp_or_status` word of the event header.
+ ///
+ /// # Errors
+ ///
+ /// - `EMSGSIZE` if the request exceeds the command queue's maximum element size.
+ /// - `ETIMEDOUT` if space does not become available to send the request, or if no event
+ /// satisfies `predicate` before the receive deadline.
+ /// - `EIO` if the command queue slot cannot hold the request headers, the receive queue is
+ /// stalled by an invalid element, or a received element fails framing validation.
+ ///
+ /// Errors from initializing the request headers and from either callback are propagated
+ /// as-is. The current valid element is consumed before a callback error is returned.
+ #[expect(dead_code)]
+ pub(crate) fn send_gmc_and_wait_event(
+ &self,
+ command_id: u32,
+ payload: &[u8],
+ timeout: Delta,
+ mut predicate: impl FnMut(u32, u32, u64, &[u8], &[u8]) -> Result<bool>,
+ mut handler: impl FnMut(u32, u32, u64, &[u8], &[u8]) -> Result,
+ ) -> Result {
+ let mut inner = self.inner.lock();
+ inner.send_command_element(RawGmcCommand {
+ command_id,
+ payload,
+ max_response_size: 0,
+ })?;
+ let dev = inner.dev;
+ let deadline = Instant::<Monotonic>::now() + timeout;
+
+ inner.await_msg_with_deadline(deadline, |message| {
+ let GspParsedMessage::Gmc(message) = message else {
+ message.log(dev);
+ return Ok(None);
+ };
+ let header = message.header();
+ let (payload_0, payload_1) = message.payload();
+ if header.command().is_response() {
+ return Ok(None);
+ }
+
+ let command = GmcCommand::from(header.command()).0;
+ let max_resp_or_status = header.raw_status_word();
+ let sequence = header.sequence();
+ if predicate(command, max_resp_or_status, sequence, payload_0, payload_1)? {
+ return Ok(Some(()));
+ }
+
+ handler(command, max_resp_or_status, sequence, payload_0, payload_1)?;
+ Ok(None)
+ })
+ }
+
/// Sends `command` to the GSP and waits for the reply.
///
/// GMC events that arrive before the reply are passed to `on_event`, and RPC messages are
diff --git a/drivers/gpu/nova-core/gsp/fw.rs b/drivers/gpu/nova-core/gsp/fw.rs
index c75488e7a787..ce4a7c45caf2 100644
--- a/drivers/gpu/nova-core/gsp/fw.rs
+++ b/drivers/gpu/nova-core/gsp/fw.rs
@@ -905,6 +905,15 @@ pub(crate) fn payload_size(&self) -> usize {
num::u32_as_usize(self.inner.size)
}
+ /// Returns the raw `max_resp_or_status` word carried by a GMC header.
+ ///
+ /// Its meaning for an event is defined by that event's command.
+ pub(crate) fn raw_status_word(&self) -> u32 {
+ // SAFETY: Both union views contain a `u32` at the same offset, so every bit pattern is
+ // valid regardless of whether the header represents a request, response, or event.
+ unsafe { self.inner.__bindgen_anon_1.request.max_response_size }
+ }
+
/// Returns the `NV_STATUS` carried by a response to a command.
///
/// Returns `Some` with the `NV_STATUS` code if the `response` flag of [`Self::command`] is set;
--
2.53.0
next prev parent reply other threads:[~2026-11-06 5:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 5:39 [PATCH v4 00/32] Introduce NVIDIA vGPU manager Alok Kumar
2026-11-06 5:39 ` [PATCH v4 01/32] gpu: nova-core: mm: retain BAR1 reservations after unmap failure Alok Kumar
2026-11-06 5:39 ` [PATCH v4 02/32] gpu: nova-core: gsp: pass boot context through setup helpers Alok Kumar
2026-11-06 5:39 ` [PATCH v4 03/32] gpu: nova-core: gsp: decouple boot context from VgpuManager Alok Kumar
2026-11-06 5:39 ` [PATCH v4 04/32] gpu: nova-core: vgpu: detect boot state independently Alok Kumar
2026-11-06 5:39 ` [PATCH v4 05/32] gpu: nova-core: gpu: add a channel ID pool for vGPU Alok Kumar
2026-11-06 5:39 ` [PATCH v4 06/32] gpu: nova-core: gsp: decode the FIFO engine table Alok Kumar
2026-11-06 5:39 ` [PATCH v4 07/32] gpu: nova-core: vgpu: initialize runtime parameters after GSP boot Alok Kumar
2026-11-06 5:39 ` [PATCH v4 08/32] gpu: nova-core: vgpu: reserve the 48-VM WPR2 heap Alok Kumar
2026-11-06 5:39 ` [PATCH v4 09/32] gpu: nova-core: mm: borrow BarUser for temporary BAR1 access Alok Kumar
2026-11-06 5:39 ` [PATCH v4 10/32] gpu: nova-core: mm: add VramBlock Alok Kumar
2026-11-06 5:39 ` [PATCH v4 11/32] gpu: nova-core: mm: add VramRegion Alok Kumar
2026-11-06 5:39 ` [PATCH v4 12/32] gpu: nova-core: mm: add BarMapping Alok Kumar
2026-11-06 5:39 ` [PATCH v4 13/32] gpu: nova-core: gsp: add synchronous GMC transactions Alok Kumar
2026-11-06 5:39 ` Alok Kumar [this message]
2026-11-06 5:39 ` [PATCH v4 15/32] gpu: nova-core: vgpu: add r000 plugin bindings Alok Kumar
2026-11-06 5:39 ` [PATCH v4 16/32] gpu: nova-core: vgpu: add VRAM slot allocator Alok Kumar
2026-11-06 5:39 ` [PATCH v4 17/32] gpu: nova-core: gsp: factor out NVKV payload conversion Alok Kumar
2026-11-06 5:39 ` [PATCH v4 18/32] gpu: nova-core: vgpu: query VF assignments and properties Alok Kumar
2026-11-06 5:39 ` [PATCH v4 19/32] gpu: nova-core: vgpu: add instance create/destroy Alok Kumar
2026-11-06 5:39 ` [PATCH v4 20/32] gpu: nova-core: vgpu: encode vGPU boot requests Alok Kumar
2026-11-06 5:39 ` [PATCH v4 21/32] gpu: nova-core: vgpu: add GSP plugin communication buffers Alok Kumar
2026-11-06 5:39 ` [PATCH v4 22/32] gpu: nova-core: vgpu: add instance boot Alok Kumar
2026-11-06 5:39 ` [PATCH v4 23/32] gpu: nova-core: vgpu: add instance shutdown Alok Kumar
2026-11-06 5:39 ` [PATCH v4 24/32] gpu: nova-core: vgpu: initialize GSP plugin RPC buffers Alok Kumar
2026-11-06 5:39 ` [PATCH v4 25/32] gpu: nova-core: vgpu: add GSP plugin RPC transactions Alok Kumar
2026-11-06 5:39 ` [PATCH v4 26/32] gpu: nova-core: vgpu: negotiate the GSP plugin RPC version Alok Kumar
2026-11-06 5:40 ` [PATCH v4 27/32] gpu: nova-core: vgpu: send GSP plugin configuration parameters Alok Kumar
2026-11-06 5:40 ` [PATCH v4 28/32] gpu: nova-core: vgpu: update the GSP plugin BME state Alok Kumar
2026-11-06 5:40 ` [PATCH v4 29/32] gpu: nova-core: vgpu: add CeUtils commands Alok Kumar
2026-11-06 5:40 ` [PATCH v4 30/32] gpu: nova-core: vgpu: scrub guest VRAM with CeUtils Alok Kumar
2026-11-06 5:40 ` [PATCH v4 31/32] gpu: nova-core: vgpu: export plugin log buffers via debugfs Alok Kumar
2026-11-06 5:40 ` [PATCH v4 32/32] gpu: nova-core: vgpu: introduce SR-IOV PF APIs Alok Kumar
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=8ddb36b189feb56642ed531e5199d3a01e7d7f5e.1793906667.git.alkumar@nvidia.com \
--to=alkumar@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=alex@shazbot.org \
--cc=aliceryhl@google.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=boqun@kernel.org \
--cc=cjia@nvidia.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kjaju@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=markus.probst@posteo.de \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=peter@colberg.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=skolothumtho@nvidia.com \
--cc=smitra@nvidia.com \
--cc=tamird@kernel.org \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
--cc=xinmengs@nvidia.com \
--cc=yishaih@nvidia.com \
--cc=zhiw@nvidia.com \
--cc=zhiwang@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
all inboxes | Powered by JetHome®