Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-09-29 Thread Zhi Wang
On 27/05/2024 22.18, Danilo Krummrich wrote: > External email: Use caution opening links or attachments > > > On Tue, May 21, 2024 at 08:32:31AM +0300, Zhi Wang wrote: >> On Mon, 20 May 2024 19:24:19 +0200 >> Danilo Krummrich wrote: >> >>> Add an abstrac

[RFC 25/29] vfio/vgpu_mgr: map mgmt heap when creating a vGPU

2024-09-29 Thread Zhi Wang
mapped into CPU vaddr. Map the mgmt heap FB memory into BAR1 and map the related BAR1 region into CPU vaddr. Initialize the pointers to the mgmt heap FB memory. Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia-vgpu/nvkm.h | 6 + drivers/vfio/pci/nvidia-vgpu/vgpu.c | 29

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-09-29 Thread Zhi Wang
On 28/05/2024 13.17, FUJITA Tomonori wrote: > External email: Use caution opening links or attachments > > > Hi, > > On Tue, 28 May 2024 08:40:20 + > Zhi Wang wrote: > >> On 27/05/2024 22.18, Danilo Krummrich wrote: >>> External email: U

Re: [RFC 00/29] Introduce NVIDIA GPU Virtualization (vGPU) Support

2024-09-29 Thread Zhi Wang
On Sun, 22 Sep 2024 05:49:22 -0700 Zhi Wang wrote: +Ben. Forget to add you. My bad. > 1. Background > = > > NVIDIA vGPU[1] software enables powerful GPU performance for workloads > ranging from graphics-rich virtual workstations to data science and > AI, enabl

[RFC 21/29] vfio/vgpu_mgr: introduce vGPU type uploading

2024-09-29 Thread Zhi Wang
. Intorduce vGPU type uploading defs and upload vGPU type specs when vGPU is enabled. Upload a default vGPU type: L40-24Q. Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia-vgpu/Makefile | 4 +- .../nvidia/inc/ctrl/ctrl2080/ctrl2080gpu.h| 33 ++ .../ctrl/ctrl2080

[RFC 16/29] nvkm/vgpu: introduce BAR1 map routines for vGPUs

2024-09-29 Thread Zhi Wang
into CPU vaddr. Expose the BAR1 map routines to NVIDIA vGPU VFIO module to map the mgmt heap. Signed-off-by: Zhi Wang --- .../nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h | 1 + drivers/gpu/drm/nouveau/nvkm/vgpu_mgr/vfio.c | 47 +++ include/drm/nvkm_vgpu_mgr_vfio.h

Re: [RFC 00/29] Introduce NVIDIA GPU Virtualization (vGPU) Support

2024-09-29 Thread Zhi Wang
On 23/09/2024 11.38, Danilo Krummrich wrote: > External email: Use caution opening links or attachments > > > On Sun, Sep 22, 2024 at 04:11:21PM +0300, Zhi Wang wrote: >> On Sun, 22 Sep 2024 05:49:22 -0700 >> Zhi Wang wrote: >> >> +Ben. >> >> For

Re: [PATCH v3 17/37] drm/nouveau/nvif: remove nvxx_client()

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:08 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Make use of nouveau_cli.name instead of nvkm_client.name. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/include/nvif/client.h | 5 - > drivers/gpu/drm/nouveau/nouveau

[RFC 29/29] vfio/vgpu_mgr: introduce NVIDIA vGPU VFIO variant driver

2024-09-29 Thread Zhi Wang
: Ankit Agrawal Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia-vgpu/Makefile | 3 + drivers/vfio/pci/nvidia-vgpu/vfio.h| 43 ++ drivers/vfio/pci/nvidia-vgpu/vfio_access.c | 297 drivers/vfio/pci/nvidia-vgpu/vfio_main.c | 511 + drivers/vfio/pci

[RFC 26/29] vfio/vgpu_mgr: allocate GSP RM client when creating vGPUs

2024-09-29 Thread Zhi Wang
A GSP RM client is required when talking to the GSP firmware via GSP RM controls. So far, all the vGPU GSP RPCs are sent via the GSP RM client allocated for vGPU manager and some vGPU GSP RPCs needs a per-vGPU GSP RM client. Allocate a dedicated GSP RM client for each vGPU. Signed-off-by: Zhi

[RFC 14/29] nvkm/vgpu: introduce channel allocation for vGPU

2024-09-29 Thread Zhi Wang
Creating a vGPU requires allocating a portion of the CHIDs from the reserved channel pool. Expose the routine of allocating the channels from the reserved channel pool to NVIDIA vGPU VFIO module for creating a vGPU. Signed-off-by: Zhi Wang --- .../nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h | 2

Re: [PATCH v3 22/37] drm/nouveau/nvif: remove client fini

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:13 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Does nothing. Remove it. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nvkm/core/client.c | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/gpu/drm/no

[RFC 27/29] vfio/vgpu_mgr: bootload the new vGPU

2024-09-29 Thread Zhi Wang
All the resources that required by a new vGPU has been set up. It is time to activate it. Send the NV2080_CTRL_CMD_VGPU_MGR_INTERNAL_BOOTLOAD_GSP_VGPU_PLUGIN_TASK GSP RPC to activate the new vGPU. Signed-off-by: Zhi Wang --- .../ctrl/ctrl2080/ctrl2080vgpumgrinternal.h | 90

[RFC 13/29] nvkm: move chid.h to nvkm/engine.

2024-09-29 Thread Zhi Wang
Move the chid.h to nvkm/engine so that vGPU manager support can expose the routines of allocating CHIDs from the reserved CHID pool to NVIDIA VFIO module when creating a vGPU. No function change is intended. Signed-off-by: Zhi Wang --- .../drm/nouveau/include/nvkm/engine/chid.h| 29

[RFC 20/29] vfio/vgpu_mgr: allocate GSP RM client for NVIDIA vGPU manager

2024-09-29 Thread Zhi Wang
A GSP RM client is required when talking to the GSP firmware via GSP RM controls. In order to create vGPUs, NVIDIA vGPU manager requires a GSP RM client to upload vGPU types to GSP. Allocate a dedicated GSP RM client for NVIDIA vGPU manager. Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia

[RFC 19/29] vfio/vgpu_mgr: introdcue vGPU lifecycle management prelude

2024-09-29 Thread Zhi Wang
: Surath Mitra Signed-off-by: Zhi Wang --- drivers/vfio/pci/Kconfig| 2 + drivers/vfio/pci/Makefile | 2 + drivers/vfio/pci/nvidia-vgpu/Kconfig| 13 drivers/vfio/pci/nvidia-vgpu/Makefile | 3 + drivers/vfio/pci/nvidia-vgpu/nvkm.h | 46

Re: [PATCH v3 27/37] drm/nouveau: move nvxx_* definitions to nouveau_drv.h

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:18 +1000 Ben Skeggs wrote: The patch looks good to me. What is the plan for these marcos in the future? When reading this patch, I was thinking do we really need both nvif layer and udevice layer? Or having one of them is good enough for the nouveau drm to talk to nvkm.

Re: [PATCH v3 37/37] drm/nouveau/kms: remove push pointer from nv50_dmac

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:28 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > The struct itself lives in nv50_dmac already, just use that. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 18 +-- > drivers/gpu/drm/nouveau/dispnv

Re: [PATCH v3 35/37] drm/nouveau: remove push pointer from nouveau_channel

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:26 +1000 Ben Skeggs wrote: With some trivial coding style fixed, Reviewed-by: Zhi Wang > The struct itself lives in nouveau_channel already, just use that. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +-- >

[RFC 17/29] nvkm/vgpu: introduce engine bitmap for vGPU

2024-09-29 Thread Zhi Wang
Activating a new vGPU needs to configure the allocated CHIDs of engines. Thus, an engine bitmap is required. Expose the engine bitmap to NVIDIA vGPU VFIO module to activate the new vGPU. Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/vgpu_mgr/vfio.c | 15 +++ include/drm

[PATCH 3/3] nvkm/gsp: handle the return of large RPC

2024-09-29 Thread Zhi Wang
-factor the low-level part of receiving RPCs from the msgq, RPC vehicle handling to merge the split RPCs back into a large RPC before handling it to the upper level. Thus, the upper-level of RPC APIs don't need to be heavily changed. Signed-off-by: Zhi Wang --- .../gpu/drm/nouveau/nvkm/subde

[RFC 23/29] vfio/vgpu_mgr: allocate vGPU channels when creating vGPUs

2024-09-29 Thread Zhi Wang
Creating a vGPU requires allocating a portion of the channels from the reserved channel pool. Allocate the channels from the reserved channel pool when creating a vGPU. Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia-vgpu/nvkm.h | 6 + drivers/vfio/pci/nvidia-vgpu/vgpu.c | 32

[PATCH 2/3] nvkm/gsp: correctly calculate the available space of the GSP cmdq buffer

2024-09-29 Thread Zhi Wang
Cc: David Airlie Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index 736cde1987d0..49721935013b 1006

[RFC 28/29] vfio/vgpu_mgr: introduce vGPU host RPC channel

2024-09-29 Thread Zhi Wang
A newly created vGPU requires some runtime configuration to be uploaded before moving on. Introduce the vGPU host RPCs manipulation APIs to send vGPU RPCs. Send vGPU RPCs to upload the runtime configuration of a vGPU. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang --- drivers/vfio/pci

[RFC 00/29] Introduce NVIDIA GPU Virtualization (vGPU) Support

2024-09-29 Thread Zhi Wang
m/XFree86/Linux-x86_64/535.154.05/NVIDIA-Linux-x86_64-535.154.05.run Zhi Wang (29): nvkm/vgpu: introduce NVIDIA vGPU support prelude nvkm/vgpu: attach to nvkm as a nvkm client nvkm/vgpu: reserve a larger GSP heap when NVIDIA vGPU is enabled nvkm/vgpu: set the VF partition count when NVIDIA vGPU

Re: [PATCH v3 18/37] drm/nouveau/nvif: remove driver keep/fini

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:09 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang Out of curiosity, when digging the nvif_driver for reviewing this patch, I found: static const struct nvif_driver * nvif_driver[] = { #ifdef __KERNEL__ &nvif_driver_nvkm, #else &nvif_dr

[RFC 04/29] nvkm/vgpu: set the VF partition count when NVIDIA vGPU is enabled

2024-09-29 Thread Zhi Wang
the GSP WPR2, if vGPU is enabled. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/include/nvkm

[RFC 12/29] nvkm/vgpu: introduce GSP RM control interface for vGPU

2024-09-29 Thread Zhi Wang
. Implement the GSP RM control interface based on nvkm routines. Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/vgpu_mgr/vfio.c | 34 include/drm/nvkm_vgpu_mgr_vfio.h | 8 + 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm

Re: [PATCH v3 36/37] drm/nouveau/kms: remove a few unused struct members and fn decls

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:27 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Left-overs from the past that are completely unused now. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 --- > drivers/gpu/drm/nouveau/dispnv50/disp.h | 9 --

[RFC 07/29] nvkm/gsp: add a notify handler for GSP event GPUACCT_PERFMON_UTIL_SAMPLES

2024-09-29 Thread Zhi Wang
unknown GSP message. Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index a7db2a7880dd..3eea6ccb6bd2 100644 --- a/drivers/gpu

Re: [PATCH v3 13/37] drm/nouveau/nvkm: remove nvkm_client_search()

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:04 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Has been unused for a while now. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/include/nvkm/core/client.h | 1 - > drivers/gpu/drm/nouveau/nvkm/core/client.c | 13 --

Re: [PATCH v3 10/37] drm/nouveau: remove abi16->handles

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:01 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Hasn't been needed since 2015... > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/dr

Re: [PATCH v3 04/37] drm/nouveau: create pci device once

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:37:55 +1000 Ben Skeggs wrote: > HW isn't touched anymore (aside from detection) until the first > nvif_device has been allocated, so we no longer need a separate > probe-only step before kicking efifb (etc) off the HW. > The patch LGTM. I am curious about what was the situ

[PATCH 0/3] NVKM GSP RPC fixes

2024-09-29 Thread Zhi Wang
using for test. [1] https://lore.kernel.org/kvm/20240922124951.1946072-1-z...@nvidia.com/T/#t [2] https://github.com/zhiwang-nvidia/linux/tree/zhi/nvkm-fixes Zhi Wang (3): nvkm/gsp: correctly advance the read pointer of GSP message queue nvkm/gsp: correctly calculate the available space of the

[RFC 02/29] nvkm/vgpu: attach to nvkm as a nvkm client

2024-09-29 Thread Zhi Wang
. Cc: Neo Jia Signed-off-by: Zhi Wang --- .../nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h | 8 .../gpu/drm/nouveau/nvkm/vgpu_mgr/vgpu_mgr.c | 48 ++- 2 files changed, 55 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h b

[RFC 08/29] nvkm/vgpu: get the size VMMU segment from GSP firmware

2024-09-29 Thread Zhi Wang
The allocation of FBMEM for vGPUs requires to be aligned with the size of VMMU segment. Before reserving the FBMEM for vGPUs, the size of VMMU segment must be known. Send a GSP RM control to get VMMU segment size from GSP firmware in vGPU support initalization. Signed-off-by: Zhi Wang

Re: [PATCH v3 32/37] drm/nouveau: remove nouveau_chan.device

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:23 +1000 Ben Skeggs wrote: LGTM. Reviewed-by: Zhi Wang > nouveau_chan.device is always the same as nouveau_chan.cli.device, > so there's no need to store it separately. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nou

Re: [PATCH v3 25/37] drm/nouveau/nvif: remove device rd/wr

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:16 +1000 Ben Skeggs wrote: Curious why the "(*{rd, wr}_32)()" are not removed together with others in this patch? Also, it would be better to put the removal of the udevice {rd, wr}* callbacks in another new patch? As the tittle of this patch is for cleaning the nvif, w

Re: [PATCH v3 09/37] drm/nouveau: remove abi16->device

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:00 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > The previous commit removes the last remnants of userspace's own nvif > instance, so this isn't needed anymore to hide the abi16 objects from > userspace and we can use nouveau_cli.device instead.

Re: [PATCH v3 31/37] drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:22 +1000 Ben Skeggs wrote: Can you elaborate a little bit about the plan for nouveau_cli and nouveau_drm? Like at what level of the function takes nouveau_cli and nouveau_drm. I understand their previous positions, but after the re-factors, their positions seem a little

[RFC 05/29] nvkm/vgpu: populate GSP_VF_INFO when NVIDIA vGPU is enabled

2024-09-29 Thread Zhi Wang
. Cc: Surath Mitra Signed-off-by: Zhi Wang --- .../nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h | 2 + .../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 3 ++ .../gpu/drm/nouveau/nvkm/vgpu_mgr/vgpu_mgr.c | 50 +++ 3 files changed, 55 insertions(+) diff --git a/drivers/gpu/drm

[RFC 09/29] nvkm/vgpu: introduce the reserved channel allocator

2024-09-29 Thread Zhi Wang
allocator. Reserve 1536 channels for vGPUs from nvkm and leave 512 CHIDs for nvkm when vGPU is enabled. Signed-off-by: Zhi Wang --- .../gpu/drm/nouveau/nvkm/engine/fifo/chid.c | 49 ++- .../gpu/drm/nouveau/nvkm/engine/fifo/chid.h | 4 ++ .../gpu/drm/nouveau/nvkm/engine/fifo

Re: [PATCH v3 00/37] drm/nouveau: misc. cleanups and removal of unused apis

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:37:51 +1000 Ben Skeggs wrote: Hi Ben: I reviewed the v3 patches. Here are some overall comments from me besides the comments in patches: 1) It would be nice that we can wrap some pointer fetch in marcos or inline functions. E.g. introduce xxx_to_yyy() to warp some pointer

Re: [PATCH v3 01/37] drm/nouveau: move nouveau_drm_device_fini() above init()

2024-09-29 Thread Zhi Wang
ock(&cli->mutex); > - nouveau_cli_fini(cli); > - kfree(cli); > - } > - mutex_unlock(&drm->clients_lock); > - > - nouveau_cli_fini(&drm->client); > - nouveau_cli_fini(&drm->master); > - destroy_workqueue(drm->sched_wq); > - nvif_parent_dtor(&drm->parent); > - mutex_destroy(&drm->clients_lock); > - kfree(drm); > -} > - > /* > * On some Intel PCIe bridge controllers doing a > * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not > reappear. Reviewed-by: Zhi Wang

Re: [PATCH v3 03/37] drm/nouveau: replace drm_device* with nouveau_drm* as dev drvdata

2024-09-29 Thread Zhi Wang
rm->client.device.info.family == > NV_DEVICE_INFO_V0_CURIE && @@ -34,7 +34,8 @@ static void > nouveau_switcheroo_set_state(struct pci_dev *pdev, >enum vga_switcheroo_state state) > { > - struct drm_device *dev = pci_get_drvdata(pdev); > + struct nouveau_drm *drm = pci_get_drvdata(pdev); > + struct drm_device *dev = drm->dev; > > if ((nouveau_is_optimus() || nouveau_is_v1_dsm()) && state > == VGA_SWITCHEROO_OFF) return; > @@ -56,21 +57,22 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev, > static void > nouveau_switcheroo_reprobe(struct pci_dev *pdev) > { > - struct drm_device *dev = pci_get_drvdata(pdev); > - drm_fb_helper_output_poll_changed(dev); > + struct nouveau_drm *drm = pci_get_drvdata(pdev); > + > + drm_fb_helper_output_poll_changed(drm->dev); > } > > static bool > nouveau_switcheroo_can_switch(struct pci_dev *pdev) > { > - struct drm_device *dev = pci_get_drvdata(pdev); > + struct nouveau_drm *drm = pci_get_drvdata(pdev); > > /* >* FIXME: open_count is protected by drm_global_mutex but > that would lead to >* locking inversion with the driver load path. And the > access here is >* completely racy anyway. So don't bother with locking for > now. */ > - return atomic_read(&dev->open_count) == 0; > + return atomic_read(&drm->dev->open_count) == 0; > } > > static const struct vga_switcheroo_client_ops Reviewed-by: Zhi Wang

[RFC 01/29] nvkm/vgpu: introduce NVIDIA vGPU support prelude

2024-09-29 Thread Zhi Wang
necessary vGPU data structures and functions to hook into the (de)initialization path of nvkm. Introduce NVIDIA vGPU data structures and functions hooking into the the (de)initialization path of nvkm and support the following patches. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang

[RFC 10/29] nvkm/vgpu: introduce interfaces for NVIDIA vGPU VFIO module

2024-09-29 Thread Zhi Wang
NVIDIA vGPU VFIO module requires interfaces from the core driver support to issue GSP RPCs, allocating FBMEM, create/destroy/reset vGPUs... Implement interfaces to expose the core driver functions to NVIDIA vGPU VFIO module. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang

Re: [PATCH v3 28/37] drm/nouveau: add nvif_mmu to nouveau_drm

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:19 +1000 Ben Skeggs wrote: Also remove cli->mem? as there seems no users for it. > This allocates a new nvif_mmu in nouveau_drm, and uses it for TTM > backend memory allocations instead of nouveau_drm.master.mmu, > which is removed by a later commit that removes nouveau

[RFC 24/29] vfio/vgpu_mgr: allocate mgmt heap when creating vGPUs

2024-09-29 Thread Zhi Wang
heap from the vGPU type. Allocate the mgmt heap from nvkm when creating a vGPU. Signed-off-by: Zhi Wang --- drivers/vfio/pci/nvidia-vgpu/nvkm.h | 6 + drivers/vfio/pci/nvidia-vgpu/vgpu.c | 32 + drivers/vfio/pci/nvidia-vgpu/vgpu_mgr.h | 6 + 3 files

Re: [PATCH v3 20/37] drm/nouveau/nvif: remove client version

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:11 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang The patch LGTM. What was the original purpose of having this version? > This is not, and has never, been used for anything. Remove it. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouve

[RFC 22/29] vfio/vgpu_mgr: allocate vGPU FB memory when creating vGPUs

2024-09-29 Thread Zhi Wang
Creating a vGPU requires allocating a portion of the FB memory from the NVKM. The size of the FB memory that a vGPU requires is from the vGPU type. Acquire the size of the required FB memory from the vGPU type. Allocate the FB memory from NVKM when creating a vGPU. Signed-off-by: Zhi Wang

Re: [PATCH v3 05/37] drm/nouveau: store nvkm_device pointer in nouveau_drm

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:37:56 +1000 Ben Skeggs wrote: > There's various different places in the drm code that get at the > nvkm_device via various creative (and not very type-safe) means. > > One of those being via nvif_device.object.priv. > > Another patch series is going to entirely remove the

Re: [PATCH v3 33/37] drm/nouveau: remove chan->drm

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:24 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > The nouveau_cli that owns the channel is now stored in nouveau_chan, > and it has a pointer to the drm device already. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dis

Re: [PATCH v3 02/37] drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common code

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:37:53 +1000 Ben Skeggs wrote: > Unify some more of the PCI/Tegra DRM driver init, both as a general > cleanup, and because a subsequent commit changes the pointer stored > via dev_set_drvdata(), and this allows the change to be made in one > place. > > Signed-off-by: Ben S

[RFC 15/29] nvkm/vgpu: introduce FB memory allocation for vGPU

2024-09-29 Thread Zhi Wang
Creating a vGPU requires allocating a mgmt heap from the FB memory. The size of the mgmt heap that a vGPU requires is from the vGPU type. Expose the FB memory allocation to NVIDIA vGPU VFIO module to allocate the mgmt heap when creating a vGPU. Signed-off-by: Zhi Wang --- .../nouveau/include

Re: [PATCH v3 24/37] drm/nouveau: always map device

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:15 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang I agree that to always map the device so that we can remove extra rd/wr callbacks in patch 25 and patch 26. Would you mind to point me the patch you mentioned to clean up this later as well? I am interested to see the

Re: [PATCH v3 30/37] drm/nouveau: pass drm to nv50_dmac_create(), rather than device+disp

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:21 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > Both of these are stored in nouveau_drm already. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 3 +-- > drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-

Re: [PATCH v3 16/37] drm/nouveau/nvif: remove nvxx_object()

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:07 +1000 Ben Skeggs wrote: > This hasn't been used in a while. > > Moves io accessors from nvkm/core/os.h to nvif/os.h at the same time > to fix a compile issue that results from no > longer being included. > Better split the patches. One for the removal of nxxx_obje

Re: [PATCH v3 34/37] drm/nouveau: remove master

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:25 +1000 Ben Skeggs wrote: Can you paste a link that shows how the workaround got removed? > The only remaining nouveau_drm.master struct member that's being used > is the mutex that protects its object tree. Move that into > nouveau_drm and remove nouveau_drm.master e

Re: [PATCH v3 07/37] drm/nouveau: add nouveau_cli to nouveau_abi16

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:37:58 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang We can also cook a patch to clean up the cli = (void *) cast in dispnv50/disp.c and nouveau_chan.c after this series is merged. > Store a pointer to struct nouveau_cli in struct nouveau_abi16 to > avoid some d

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-09-29 Thread Zhi Wang
On Mon, 20 May 2024 19:24:19 +0200 Danilo Krummrich wrote: > Add an abstraction around the kernels firmware API to request firmware > images. The abstraction provides functions to access the firmware > buffer and / or copy it to a new buffer allocated with a given > allocator backend. > Was pla

Re: [PATCH v3 02/37] drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common code

2024-09-29 Thread Zhi Wang
t; err = PTR_ERR(drm); > goto err_free; > @@ -1387,12 +1416,10 @@ nouveau_platform_device_create(const struct > nvkm_device_tegra_func *func, if (err) > goto err_put; > > - platform_set_drvdata(pdev, drm); > - > - return drm; > + return drm->dev; > > err_put: > - drm_dev_put(drm); > + nouveau_drm_device_del(drm); > err_free: > nvkm_device_del(pdevice); > > diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c > b/drivers/gpu/drm/nouveau/nouveau_platform.c index > bf2dc7567ea4..d0a63f0f54a2 100644 --- > a/drivers/gpu/drm/nouveau/nouveau_platform.c +++ > b/drivers/gpu/drm/nouveau/nouveau_platform.c @@ -34,12 +34,6 @@ > static int nouveau_platform_probe(struct platform_device *pdev) if > (IS_ERR(drm)) return PTR_ERR(drm); > > - ret = drm_dev_register(drm, 0); > - if (ret < 0) { > - drm_dev_put(drm); > - return ret; > - } > - > return 0; > } > Reviewed-by: Zhi Wang

[RFC 18/29] nvkm/vgpu: introduce pci_driver.sriov_configure() in nvkm

2024-09-29 Thread Zhi Wang
pci_driver.sriov_configure() in nvkm. Introduce a blocking call chain to let NVIDIA vGPU manager handle this event. Signed-off-by: Zhi Wang --- .../nouveau/include/nvkm/vgpu_mgr/vgpu_mgr.h | 1 + drivers/gpu/drm/nouveau/nvkm/device/pci.c | 14 +++ .../gpu/drm/nouveau/nvkm/vgpu_mgr/vgpu_mgr.c | 25

Re: [RFC PATCH 7/8] rust: add firmware abstractions

2024-09-29 Thread Zhi Wang
On 28/05/2024 17.18, Danilo Krummrich wrote: > External email: Use caution opening links or attachments > > > On Tue, May 28, 2024 at 08:40:20AM +0000, Zhi Wang wrote: >> On 27/05/2024 22.18, Danilo Krummrich wrote: >>> External email: Use caution opening links or att

[RFC 03/29] nvkm/vgpu: reserve a larger GSP heap when NVIDIA vGPU is enabled

2024-09-29 Thread Zhi Wang
A larger GSP heap is required when enabling NVIDIA vGPU. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers

[PATCH 1/3] nvkm/gsp: correctly advance the read pointer of GSP message queue

2024-09-29 Thread Zhi Wang
c: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Cc: Danilo Krummrich Cc: David Airlie Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/driv

Re: [PATCH v3 11/37] drm/nouveau/nvkm: remove detect/mmio/subdev_mask from device args

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:02 +1000 Ben Skeggs wrote: Reviewed-by: Zhi Wang > All callers now pass "detect=true, mmio=true, subdev_mask=~0ULL", > so remove the function arguments, and associated code. > > Signed-off-by: Ben Skeggs > --- > .../gpu/drm/nouveau/inc

Re: [PATCH v3 29/37] drm/nouveau: pass drm to nouveau_mem_new(), instead of cli

2024-09-29 Thread Zhi Wang
On Fri, 26 Jul 2024 14:38:20 +1000 Ben Skeggs wrote: LGTM. Reviewed-by: Zhi Wang > The nouveau_cli pointer is only ever used to eventually access > nouveau_drm, so just store it directly. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/no

Re: [PATCH v3 06/37] drm/nouveau: move allocation of root client out of nouveau_cli_init()

2024-09-29 Thread Zhi Wang
With the workaround "if (cli!= drm->master.base)" removed in "[PATCH v3 34/37] drm/nouveau: remove master": Reviewed-by: Zhi Wang On Fri, 26 Jul 2024 14:37:57 +1000 Ben Skeggs wrote: > drm->master isn't really a nouveau_cli, and is mostly just used to get &g

[RFC 06/29] nvkm/vgpu: set RMSetSriovMode when NVIDIA vGPU is enabled

2024-09-29 Thread Zhi Wang
The registry object "RMSetSriovMode" is required to be set when vGPU is enabled. Set "RMSetSriovMode" to 1 when nvkm is loading the GSP firmware and initialize the GSP registry objects, if vGPU is enabled. Cc: Neo Jia Cc: Surath Mitra Signed-off-by: Zhi Wang --- drivers/

[RFC 11/29] nvkm/vgpu: introduce GSP RM client alloc and free for vGPU

2024-09-29 Thread Zhi Wang
To talk to the GSP firmware, the first step is allocating a GSP RM client. NVDIA vGPU VFIO module requires a GSP RM client to obtain system information and create and configure vGPUs. Implement the GSP client allocation and free. Signed-off-by: Zhi Wang --- drivers/gpu/drm/nouveau/nvkm

Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive

2024-05-03 Thread Zhi Wang
t; for users of I2C_ALGOBIT bitbanging interface, now that the approved > verbiage exists in the specification. > > Compile tested, no functionality changes intended > For GVT part, Acked-by: Zhi Wang Thanks, Zhi. > [1]: > https://lore.kernel.org/all/20240322132619.6389-1-wsa+ren

Re: [Nouveau] [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro

2017-10-10 Thread Zhi Wang
Thanks for the patch! :) 2017-10-01 22:30 GMT+03:00 Jérémy Lefaure : > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof >