[PATCH v3 0/8] gpu: nova-core: boot GSP with vGPU enabled

Zhi Wang <[email protected]>
Newsgroups dev.linux.lists.nova-gpu,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Booting up GSP with vGPU enabled is part of the first milestone (M1)
together with the Rust fwctl abstraction [1] and the nova-core fwctl
driver [2] for upstream vGPU support. It allows us to validate the basic
GSP boot flow with vGPU enabled and upload vGPU types even before the
remaining nova-core dependencies are ready. The nova-vgpu WIP patches
for all milestones can be found at [3].

This version is based on drm-rust-next plus Alexandre's GSP boot process
consolidation series [4].

v3:

- Split the FSP response header rename from the FSP PRC vGPU mode query
  into a separate patch.
- Change pci_sriov_get_totalvfs() to return unsigned int on the C side
  while keeping the Rust helper as u16.
- Move the vGPU capability gate into a dedicated vgpu::hal module.
- Represent detected vGPU state as VgpuState instead of separate
  enabled/total_vfs accessors.
- Keep total_vfs values below 2 on the disabled path, with an explicit
  comment for the current single-VF limitation.
- Use the generated 570.144 GSP_FW_HEAP_SIZE_VGPU_DEFAULT binding for
  vGPU WPR2 heap sizing, and keep unsupported 0/1-VF states out of the
  vGPU heap path through VgpuState.

v2:

- Rebase on top of Alexandre's GSP boot process consolidation series.
- Drop the FSP response, FSP documentation, and GspBootContext patches
  that are already in drm-rust-next or superseded by the prerequisite
  boot consolidation series.
- Change pci_sriov_get_totalvfs() to return u16 and update existing C
  callers accordingly.
- Make the Rust sriov_get_totalvfs() helper return u16 directly.
- Rework the FSP PRC vGPU mode query to use typed subcommand, object ID,
  flags, request, and response structures.
- Move vGPU state detection before GSP boot into a read-only VgpuManager,
  avoiding Mutex/Cell based mutation during boot.
- Add a HAL method for the vGPU capability gate.
- Split the SetRegistry changes into a dynamic-entry refactor and the
  RMSetSriovMode functional change.
- Rework WPR2 heap sizing to consume VgpuManager, keep the vGPU heap-size
  helper in gsp/fw.rs, and drop the 1VM heap-size special case.

[1] https://lore.kernel.org/rust-for-linux/[email protected]/
[2] https://lore.kernel.org/rust-for-linux/[email protected]/
[3] https://github.com/zhiwang-nvidia/nova-core/tree/zhi/nova-vgpu-wip
[4] https://lore.kernel.org/all/[email protected]/

Zhi Wang (8):
  PCI/IOV: Return unsigned int from pci_sriov_get_totalvfs()
  rust: pci: add sriov_get_totalvfs() helper
  gpu: nova-core: fsp: rename FSP response header type
  gpu: nova-core: read vGPU mode from FSP via PRC protocol
  gpu: nova-core: add vGPU preludes
  gpu: nova-core: build SetRegistry entries dynamically
  gpu: nova-core: set RMSetSriovMode for vGPU
  gpu: nova-core: reserve vGPU WPR2 heap

 drivers/gpu/nova-core/fb.rs                   |  25 ++-
 drivers/gpu/nova-core/fsp.rs                  | 189 +++++++++++++++++-
 drivers/gpu/nova-core/gpu.rs                  |   7 +
 drivers/gpu/nova-core/gsp.rs                  |   2 +
 drivers/gpu/nova-core/gsp/boot.rs             |  17 +-
 drivers/gpu/nova-core/gsp/commands.rs         |  80 +++++---
 drivers/gpu/nova-core/gsp/fw.rs               |   5 +
 .../gpu/nova-core/gsp/fw/r570_144/bindings.rs |   1 +
 drivers/gpu/nova-core/mctp.rs                 |   3 +
 drivers/gpu/nova-core/nova_core.rs            |   1 +
 drivers/gpu/nova-core/vgpu.rs                 |  79 ++++++++
 drivers/gpu/nova-core/vgpu/hal.rs             |  45 +++++
 drivers/pci/iov.c                             |   2 +-
 include/linux/pci.h                           |   4 +-
 rust/kernel/pci.rs                            |  11 +
 15 files changed, 425 insertions(+), 46 deletions(-)
 create mode 100644 drivers/gpu/nova-core/vgpu.rs
 create mode 100644 drivers/gpu/nova-core/vgpu/hal.rs


base-commit: 05508fc305cb0311ee21f9629a41f821f5e0216f
-- 
2.51.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.