linux-kernel - Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <64be6d1f5fd70c8f0e3988d4220212b9f3d1d418.camel@nvidia.com>
Date: Sat, 20 Dec 2025 21:30:48 +0000
From: Timur Tabi <ttabi@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>, Joel Fernandes
	<joelagnelf@...dia.com>
CC: "gary@...yguo.net" <gary@...yguo.net>, "lossin@...nel.org"
	<lossin@...nel.org>, "ojeda@...nel.org" <ojeda@...nel.org>,
	"boqun.feng@...il.com" <boqun.feng@...il.com>, "a.hindborg@...nel.org"
	<a.hindborg@...nel.org>, "simona@...ll.ch" <simona@...ll.ch>,
	"tmgross@...ch.edu" <tmgross@...ch.edu>, "nouveau@...ts.freedesktop.org"
	<nouveau@...ts.freedesktop.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, "bjorn3_gh@...tonmail.com"
	<bjorn3_gh@...tonmail.com>, Eliot Courtney <ecourtney@...dia.com>,
	"aliceryhl@...gle.com" <aliceryhl@...gle.com>, "kwilczynski@...nel.org"
	<kwilczynski@...nel.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "dakr@...nel.org" <dakr@...nel.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>, Alistair Popple
	<apopple@...dia.com>
Subject: Re: [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP
 command GSP upon unloading

On Fri, 2025-12-19 at 12:39 +0900, Alexandre Courbot wrote:



> Does Nouveau really handle all messages asynchronously? Just taking a
> look at `r535_gsp_rpc_send` I see:
> 
> * A potential busy-loop with `r535_gsp_rpc_handle_reply`, An argument to
> * define whether we should wait for a reply (`policy`).
> 
> So it seems like each GSP command expecting a reply is effectively
> looping until it arrives, with some messages (LIBOS_PRINT, SEQUENCER,
> etc.) being managed by a notifier registered with the command queue. But
> messages sent explicitly by the driver don't seem to make use of it and
> instead process messages until they find their reply.

Yes, you're right.  But the difference is that in Nouveau, all message processing is handled by
r535_gsp_msg_recv(), which always also handles all of the asynchronous "other" messages.

The above `loop` expression in Nova doesn't do that.  It's missing the asynchronous handler. 
This is the crux of my concern.

> This seems to work because IIUC the GSP sends replies in the same order
> as it received the messages (so one caller cannot consume the reply
> intended to another) and GSP messages are a replacement for the CPU
> messing with the hardware itself anyway. So in that context that design
> is not particularly awful, but maybe we will want to switch to something
> interrupt-based in Nova long-term anyway.

Sure, but we still need to do it the way Nouveau handles it.  We need our own version of
r535_gsp_rpc_handle_reply() which unifies handling of all incoming messages, either polling or
interrupt-based.

For now, we can always pass NVKM_GSP_RPC_REPLY_POLL or NVKM_GSP_RPC_REPLY_RECV, which are
polling-based.  NVKM_GSP_RPC_REPLY_NOWAIT is apparently interrupt-based, which I believe is
triggered via r535_gsp_msgq_work().