search for: vgpu

...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...

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...

...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_...

...rm/i915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #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; @@ -679,6 +682,7 @@ static int intel_vgpu_crea...

...rm/i915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #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 const 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; @@ -678,7 +681,7 @@ static int intel_vgp...

...> > > #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) > > { > &g...

...rm/i915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #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 const 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; @@ -678,7 +681,7 @@ static int intel_vgp...

...export/import qxl buffer objects from/to other devices. Problem is that we have no way to signal to userspace that prime can be used that way. Setting DRM_PRIME_CAP_{IMPORT,EXPORT} even though the driver can't do that leads to other problems. Userspace thinks it can have other devices (intel vgpu for example) handle the rendering, then import the rendered buffer into qxl for scanout. Should we add something like DRM_PRIME_CAP_SAME_DEVICE? cheers, Gerd

...itch 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 typo: "Reporducer" > 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/d...

...915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #include <linux/kvm_host.h> #include <linux/vfio.h> #include <linux/mdev.h> +#include <linux/mdev_vfio_ops.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 const struct mdev_vfio_device_ops intel_vfio_vgpu_dev_ops; + static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev) { struct intel_vgpu *vgpu = NULL; @@ -678,7 +681,7 @@ static int intel_vgp...

...915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #include <linux/kvm_host.h> #include <linux/vfio.h> #include <linux/mdev.h> +#include <linux/mdev_vfio_ops.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 const struct mdev_vfio_device_ops intel_vfio_vgpu_dev_ops; + static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev) { struct intel_vgpu *vgpu = NULL; @@ -678,7 +681,7 @@ static int intel_vgp...

...915/gvt/kvmgt.c @@ -42,6 +42,7 @@ #include <linux/kvm_host.h> #include <linux/vfio.h> #include <linux/mdev.h> +#include <linux/mdev_vfio_ops.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 const struct mdev_vfio_device_ops intel_vfio_vgpu_dev_ops; + static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev) { struct intel_vgpu *vgpu = NULL; @@ -678,7 +681,7 @@ static int intel_vgp...

...from/to other devices. > > Problem is that we have no way to signal to userspace that prime can > be used that way. > > Setting DRM_PRIME_CAP_{IMPORT,EXPORT} even though the driver can't > do that leads to other problems. Userspace thinks it can have other > devices (intel vgpu for example) handle the rendering, then import > the rendered buffer into qxl for scanout. > > Should we add something like DRM_PRIME_CAP_SAME_DEVICE? Yeah I expect we need some sort of same device only capability, so that dri3 userspace can work. If we just fail importing in these cases...