This is the initial series for the nova-core stub driver.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-cor
The `LocalModule` type is the type of the module created by `module!`,
`module_pci_driver!`, `module_platform_driver!`, etc.
Since the exact type of the module is sometimes generated on the fly by
the listed macros, provide an alias.
This is first used by the `module_firmware!` macro introduced i
`BStr` already dereference to `&[u8]` through the `Deref` trait,
however, this can't be called from const context.
Hence, provide a separate const function for this.
This is used in subsequent nova-core patches.
Signed-off-by: Danilo Krummrich
---
rust/kernel/str.rs | 6 ++
1 file changed,
Add the initial documentation of the Nova project.
The initial project documentation consists out of a brief introduction
of the project, as well as project guidelines both general and nova-core
specific and a task list for nova-core specifically.
The task list is divided into tasks for general R
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in
Analogous to the `module!` macro `module_firmware!` adds additional
firmware path strings to the .modinfo section.
In contrast to `module!`, where path strings need to be string literals,
path strings can be composed with the `firmware::ModInfoBuilder`.
Some drivers require a lot of firmware file
The `firmware` field of the `module!` only accepts literal strings,
which is due to the fact that it is implemented as a proc macro.
Some drivers require a lot of firmware files (such as nova-core) and
hence benefit from more flexibility composing firmware path strings.
The `firmware::ModInfoBuil
Thanks for the poke! This patch looks fine to me:
Reviewed-by: Lyude Paul
I'll push it to drm-misc in a moment
On Wed, 2025-02-26 at 10:02 +0100, Thomas Zimmermann wrote:
> Ping. Are there any comments on this patch?
>
> Am 14.01.25 um 10:57 schrieb Thomas Zimmermann:
> > Keep user-forced conn
For the whole series:
Reviewed-by: Lyude Paul
On Tue, 2025-02-25 at 22:53 +, Zhi Wang wrote:
> Hi folks:
>
> Here are the v2 version of NVKM GSP RPC message handling policy which
> solves the issue reported by Ben. More details can be found in v1 [1].
>
> v2:
>
> - Add Fixes: tag. (Danilo
On Wed, Feb 26, 2025 at 02:16:58AM +0100, Danilo Krummrich wrote:
> > DRM achieves this, in part, by using drm_dev_unplug().
>
> No, DRM can have concurrent driver code running, which is why drm_dev_enter()
> returns whether the device is unplugged already, such that subsequent
> operations, (e.g.
On Wed, Feb 26, 2025 at 01:21:20PM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 02:16:58AM +0100, Danilo Krummrich wrote:
> > Again, the reason a pci::Bar needs to be revocable in Rust is that we can't
> > have
> > the driver potentially keep the pci::Bar alive (or even access it) after
On Wed, Feb 26, 2025 at 10:31:10PM +0100, Danilo Krummrich wrote:
> Let's take a step back and look again why we have Devres (and Revocable) for
> e.g. pci::Bar.
>
> The device / driver model requires that device resources are only held by a
> driver, as long as the driver is bound to the device.
On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> The way misc device works you can't unload the module until all the
> FDs are closed and the misc code directly handles races with opening
> new FDs while modules are unloading. It is quite a different scheme
> than discussed in thi
On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
>> The way misc device works you can't unload the module until all the
>> FDs are closed and the misc code directly handles races with opening
>> new FDs while modules are unloading
There can be multiple cases of handling the GSP RPC messages, which are
the reply of GSP RPC commands according to the requirement of the
callers and the nature of the GSP RPC commands.
The current supported reply policies are "callers don't care" and "receive
the entire message" according to the
Hi folks:
Here are the v3 version of NVKM GSP RPC message handling policy which
solves the issue reported by Ben. More details can be found in v1 [1].
v3:
- Fix a hidden use-after-free caught by KFENCE in PATCH 1,
r535_gsp_rpc_send(). (Ben)
Zhi Wang (2):
drm/nouveau/nvkm: factor out current
On 26/02/2025 11.32, Lyude Paul wrote:
> For the whole series:
>
> Reviewed-by: Lyude Paul
>
Hi Lyude:
Thanks so much for the RB. Ben found a hidden use-after-free after
enabling the KFENCE in v3.I re-spined it with a minor fixes. Please
review. Sorry for that.
Z.
> On Tue, 2025-02-25 at 2
On Thu, 2025-02-27 at 01:35 +, Zhi Wang wrote:
> +/**
> + * DOC: GSP message handling policy
> + *
> + * When sending a GSP RPC command, there can be multiple cases of handling
> + * the GSP RPC messages, which are the reply of GSP RPC commands, according
> + * to the requirement of the callers
Some GSP RPC commands need a new reply policy: "caller don't care about
the message content but want to make sure a reply is received". To
support this case, a new reply policy is introduced.
NV_VGPU_MSG_FUNCTION_ALLOC_MEMORY is a large GSP RPC command. The actual
required policy is NVKM_GSP_RPC_R
Ping. Are there any comments on this patch?
Am 14.01.25 um 10:57 schrieb Thomas Zimmermann:
Keep user-forced connector status even if it cannot be programmed. Same
behavior as for the rest of the drivers.
Signed-off-by: Thomas Zimmermann
---
This patch is in preparation of
https://patchwork.fr
Hi
Am 25.02.25 um 14:45 schrieb Tomi Valkeinen:
Hi,
On 21/02/2025 11:19, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 6
21 matches
Mail list logo
