search for: vgpu

...u. My bad. Please also add the driver maintainers! I had to fetch the patchset from the KVM list, since they did not hit the nouveau list (I'm trying to get @nvidia.com addresses whitelisted). - Danilo > > > > 1. Background > > ============= > > > > NVIDIA vGPU[1] software enables powerful GPU performance for workloads > > ranging from graphics-rich virtual workstations to data science and > > AI, enabling IT to leverage the management and security benefits of > > virtualization as well as the performance of NVIDIA GPUs required for >...

Hi Zhi, Thanks for the very detailed cover letter. On Sun, Sep 22, 2024 at 05:49:22AM -0700, Zhi Wang wrote: > 1. Background > ============= > > NVIDIA vGPU[1] software enables powerful GPU performance for workloads > ranging from graphics-rich virtual workstations to data science and AI, > enabling IT to leverage the management and security benefits of > virtualization as well as the performance of NVIDIA GPUs required for > modern workloa...

> From: Zhi Wang <zhiw at nvidia.com> > Sent: Sunday, September 22, 2024 8:49 PM > [...] > > The NVIDIA vGPU VFIO module together with VFIO sits on VFs, provides > extended management and features, e.g. selecting the vGPU types, support > live migration and driver warm update. > > Like other devices that VFIO supports, VFIO provides the standard > userspace APIs for device lifecycle manage...

...and the blockers with the device / > driver infrastructure have been resolved and we're able to move forward. Besides > that, Dave made great progress on the firmware abstraction side of things. > > Is this more of a proof of concept? Do you plan to work on Nova in general and > vGPU support for Nova? This is intended to be a real product that customers would use, it is not a proof of concept. There is alot of demand for this kind of simplified virtualization infrastructure in the host side. The series here is the first attempt at making thin host infrastructure and Zhi/etc ar...

On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote: > On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote: > > > > No, I do object to "we are ignoring the driver being proposed by the > > developers involved for this hardware by adding to the old one instead" > > which it seems like is happening here. > > That is too harsh. We've

On Fri, Sep 27, 2024 at 04:22:32PM +0200, Danilo Krummrich wrote: > > When you say things like this it comes across as though you are > > implying there are two tiers to the community. Ie those that set the > > strategy and those that don't. > > This isn't true, I just ask you to consider the goals that have been set > already, because we have been working on

On Fri, Sep 27, 2024 at 09:51:15AM -0300, Jason Gunthorpe wrote: > On Fri, Sep 27, 2024 at 12:42:56AM +0200, Danilo Krummrich wrote: > > On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote: > > > > > > > > No, I do object to "we are ignoring the driver being proposed by the

...f(T)) ) Signed-off-by: Jérémy Lefaure <jeremy.lefaure at lse.epita.fr> --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 +++++---- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 9 +++++---- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 9 ++++----- drivers/gpu/drm/i915/gvt/vgpu.c | 3 ++- drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 7 ++++--- drivers/gpu/drm/via/via_verifier.c | 10 ++++------ 6 files changed, 24 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c i...

On Fri, Sep 27, 2024 at 12:42:56AM +0200, Danilo Krummrich wrote: > On Thu, Sep 26, 2024 at 11:40:57AM -0300, Jason Gunthorpe wrote: > > On Thu, Sep 26, 2024 at 02:54:38PM +0200, Greg KH wrote: > > > > > > No, I do object to "we are ignoring the driver being proposed by the > > > developers involved for this hardware by adding to the old one instead"

...ayload for libos print buffers > > Is this structure versioned? If so, does it relate to a specific GSP-RM version? Yes, the structure is versioned, but it's a little weird. When a new RPC is added, the developer can choose to use any version number that matches the "current" VGPU version or earlier. src/nvidia/generated/g_rpc-structures.h is generated from a special "def" file, and the developer just chooses whatever number he wants. Typically, the developer will choose whatever version that VGPU is at when he starts working on the code. But since this is the f...

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 division. I tried to divide the changes into a patch per subsystem (excepted for staging). If one of the patch should be split into several patches, let me know. In order to reduce

...ng any vga ioport will switch the qxl device into vga mode. The qxl driver never does that, but other drivers accessing vga ports can trigger that too and therefore disturb qxl operation. So aquire the legacy vga ioports from vgaarb to avoid that. Reporducer: Boot kvm guest with both qxl and i915 vgpu, with qxl being first in pci scan order. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index b57a37543613..8a...

...> > > > Is this structure versioned? If so, does it relate to a specific GSP-RM version? > > Yes, the structure is versioned, but it's a little weird. When a new RPC is > added, the developer can choose to use any version number that matches the > "current" VGPU version or earlier. src/nvidia/generated/g_rpc-structures.h > is generated from a special "def" file, and the developer just chooses > whatever number he wants. Typically, the developer will choose whatever > version that VGPU is at when he starts working on the code. But sinc...

...ng any vga ioport will switch the qxl device into vga mode. The qxl driver never does that, but other drivers accessing vga ports can trigger that too and therefore disturb qxl operation. So aquire the legacy vga ioports from vgaarb to avoid that. Reproducer: Boot kvm guest with both qxl and i915 vgpu, with qxl being first in pci scan order. v2: Skip this for secondary qxl cards which don't have vga mode in the first place (Frediano). Cc: Frediano Ziglio <fziglio at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 20 +++++...

...t; #include <linux/kvm_host.h> > #include <linux/vfio.h> > #include <linux/mdev.h> > +#include <linux/vfio_mdev.h> > #include <linux/debugfs.h> > > #include <linux/nospec.h> > @@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu) > vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device); > } > > +static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops; > + > static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev) > { > struct intel_vgpu *vgpu = NULL; > @...

...t; #include <linux/kvm_host.h> > #include <linux/vfio.h> > #include <linux/mdev.h> > +#include <linux/vfio_mdev.h> > #include <linux/debugfs.h> > > #include <linux/nospec.h> > @@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu) > vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device); > } > > +static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops; > + > static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev) > { > struct intel_vgpu *vgpu = NULL; > @...

On Sat, 12 Jan 2019 at 07:13, Dave Airlie <airlied at gmail.com> wrote: > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > > userspace. It's been pointed out to me that disables DRI3 for these

On Sat, 12 Jan 2019 at 07:13, Dave Airlie <airlied at gmail.com> wrote: > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL, > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to > > userspace. It's been pointed out to me that disables DRI3 for these

...ree)/$(src) komeda-y := \ komeda_drv.o \ diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile index 271fb46..ea8324a 100644 --- a/drivers/gpu/drm/i915/gvt/Makefile +++ b/drivers/gpu/drm/i915/gvt/Makefile @@ -5,5 +5,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \ execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \ fb_decoder.o dmabuf.o page_track.o -ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) +ccflags-y += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/ i915-y += $(addprefix $(GVT_...

.../../include obj-$(CONFIG_CHASH) += chash.o diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile index b016dc7..a4a5a96 100644 --- a/drivers/gpu/drm/i915/gvt/Makefile +++ b/drivers/gpu/drm/i915/gvt/Makefile @@ -5,6 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \ execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \ fb_decoder.o dmabuf.o page_track.o -ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) +ccflags-y += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/ i915-y += $(addprefix $(GVT_...