Skip to contentSkip to conversation

Deliver vGPU display vblank event to userspace

RFC PATCH Superseded Tina Zhang 4 participants 21 messages Jun 27, 2019 – Jul 1, 2019

Subsystems (5)
DRM drivers KVM Intel i915 VFIO driver +1 more subsystems

v3 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

Tina Zhang

author
#0 lore raw

v3 cover Deliver vGPU display vblank event to userspace

This series tries to send the vGPU display vblank event to user land.

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the updated framebuffer.

With vGPU's vblank event working as a timer, userspace still needs to query the framebuffer first, before getting a new dma-buf for it.

v3:
- Deliver display vblank event instead of page flip event. (Zhenyu) v2:
- Use VFIO irq chain to get eventfds from userspace instead of adding a new ABI. (Alex)
v1:
- https://patchwork.kernel.org/cover/10962341/

Tina Zhang (4):
vfio: Define device specific irq type capability
vfio: Introduce vGPU display irq type drm/i915/gvt: Register vGPU display vblank irq drm/i915/gvt: Deliver vGPU vblank event to userspace

 drivers/gpu/drm/i915/gvt/display.c   |  14 +-
 drivers/gpu/drm/i915/gvt/gvt.h       |   6 +
 drivers/gpu/drm/i915/gvt/hypercall.h |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c     | 193 +++++++++++++++++++++++++--
 drivers/gpu/drm/i915/gvt/mpt.h       |  17 +++
 include/uapi/linux/vfio.h            |  22 ++-
 6 files changed, 241 insertions(+), 12 deletions(-)
Signature · 1 line
2.17.1
author
#1 lore raw

RFC PATCH v3 1/4 vfio: Define device specific irq type capability

Cap the number of irqs with fixed indexes and use capability chains to chain device specific irqs.

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)
include/uapi/linux/vfio.h +18 -1
index 02bb7ad6e986..600784acc4ac 100644
@@ -444,11 +444,27 @@ struct vfio_irq_info {
 #define VFIO_IRQ_INFO_MASKABLE		(1 << 1)
 #define VFIO_IRQ_INFO_AUTOMASKED	(1 << 2)
 #define VFIO_IRQ_INFO_NORESIZE		(1 << 3)
+#define VFIO_IRQ_INFO_FLAG_CAPS		(1 << 4) /* Info supports caps */
 	__u32	index;		/* IRQ index */
+	__u32	cap_offset;	/* Offset within info struct of first cap */
 	__u32	count;		/* Number of IRQs within this index */
 };
 #define VFIO_DEVICE_GET_IRQ_INFO	_IO(VFIO_TYPE, VFIO_BASE + 9)
 
+/*
+ * The irq type capability allows irqs unique to a specific device or
+ * class of devices to be exposed.
+ *
+ * The structures below define version 1 of this capability.
+ */
+#define VFIO_IRQ_INFO_CAP_TYPE      3
+
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */
+};
+
 /**
  * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
  *

@@ -550,7 +566,8 @@ enum {
 	VFIO_PCI_MSIX_IRQ_INDEX,
 	VFIO_PCI_ERR_IRQ_INDEX,
 	VFIO_PCI_REQ_IRQ_INDEX,
-	VFIO_PCI_NUM_IRQS
+	VFIO_PCI_NUM_IRQS = 5	/* Fixed user ABI, IRQ indexes >=5 use   */
+				/* device specific cap to define content */
 };
 
 /*
Signature · 1 line
2.17.1
#2 lore raw

Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 13 lines · On Thu, 27 Jun 2019 11:37:59 +0800 Tina Zhang <[email protected]> wrote:

Cap the number of irqs with fixed indexes and use capability chains to chain device specific irqs.

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)
include/uapi/linux/vfio.h +0 -0
index 02bb7ad6e986..600784acc4ac 100644

include/uapi/linux/vfio.h struct vfio_irq_info { · line 451

Quoted 8 lines
include/uapi/linux/vfio.h +2 -0
@@ -444,11 +444,27 @@ struct vfio_irq_info {
 #define VFIO_IRQ_INFO_MASKABLE		(1 << 1)
 #define VFIO_IRQ_INFO_AUTOMASKED	(1 << 2)
 #define VFIO_IRQ_INFO_NORESIZE		(1 << 3)
+#define VFIO_IRQ_INFO_FLAG_CAPS		(1 << 4) /* Info supports caps */
 	__u32	index;		/* IRQ index */
+	__u32	cap_offset;	/* Offset within info struct of first cap */
 	__u32	count;		/* Number of IRQs within this index */
 };

This cannot be inserted into the middle of the structure, it breaks compatibility with all existing userspace binaries. I must be added to the end of the structure.

Quoted 29 lines
include/uapi/linux/vfio.h +16 -1
 #define VFIO_DEVICE_GET_IRQ_INFO	_IO(VFIO_TYPE, VFIO_BASE + 9)
 
+/*
+ * The irq type capability allows irqs unique to a specific device or
+ * class of devices to be exposed.
+ *
+ * The structures below define version 1 of this capability.
+ */
+#define VFIO_IRQ_INFO_CAP_TYPE      3
+
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */
+};
+
 /**
  * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
  *

@@ -550,7 +566,8 @@ enum {
 	VFIO_PCI_MSIX_IRQ_INDEX,
 	VFIO_PCI_ERR_IRQ_INDEX,
 	VFIO_PCI_REQ_IRQ_INDEX,
-	VFIO_PCI_NUM_IRQS
+	VFIO_PCI_NUM_IRQS = 5	/* Fixed user ABI, IRQ indexes >=5 use   */
+				/* device specific cap to define content */
 };
 
 /*
author
#3 lore raw

RE: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 34 lines

-----Original Message-----
From: Alex Williamson [mailto:[email protected]]
Sent: Thursday, June 27, 2019 12:08 PM
To: Zhang, Tina <[email protected]>
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]; [email protected]; Lv, Zhiyuan <[email protected]>; Wang, Zhi A <[email protected]>; Tian, Kevin <[email protected]>; Yuan, Hang <[email protected]>
Subject: Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 13 lines · On Thu, 27 Jun 2019 11:37:59 +0800 Tina Zhang <[email protected]> wrote:

Cap the number of irqs with fixed indexes and use capability chains to chain device specific irqs.

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)
include/uapi/linux/vfio.h +0 -0
index 02bb7ad6e986..600784acc4ac 100644

include/uapi/linux/vfio.h struct vfio_irq_info { · line 447

Quoted 4 lines
include/uapi/linux/vfio.h +1 -0
@@ -444,11 +444,27 @@ struct vfio_irq_info {
 #define VFIO_IRQ_INFO_MASKABLE		(1 << 1)
 #define VFIO_IRQ_INFO_AUTOMASKED	(1 << 2)
 #define VFIO_IRQ_INFO_NORESIZE		(1 << 3)
+#define VFIO_IRQ_INFO_FLAG_CAPS		(1 << 4) /* Info

supports caps */

Quoted 9 lines

include/uapi/linux/vfio.h struct vfio_irq_info { · line 451

Quoted 4 lines
include/uapi/linux/vfio.h +1 -0
 	__u32	index;		/* IRQ index */
+	__u32	cap_offset;	/* Offset within info struct of first cap */
 	__u32	count;		/* Number of IRQs within this index */
 };

This cannot be inserted into the middle of the structure, it breaks compatibility with all existing userspace binaries. I must be added to the end of the structure.

Indeed. Thanks.

BR,
Tina

Quoted 33 lines

include/uapi/linux/vfio.h struct vfio_irq_info { · line 452

Quoted 2 lines
include/uapi/linux/vfio.h +0 -0
 #define VFIO_DEVICE_GET_IRQ_INFO	_IO(VFIO_TYPE, VFIO_BASE +

9)

Quoted 7 lines
include/uapi/linux/vfio.h +6 -0
+/*
+ * The irq type capability allows irqs unique to a specific device or
+ * class of devices to be exposed.
+ *
+ * The structures below define version 1 of this capability.
+ */

include/uapi/linux/vfio.h struct vfio_irq_info {

Quoted 10 lines
include/uapi/linux/vfio.h +8 -0
+#define VFIO_IRQ_INFO_CAP_TYPE      3
+
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */
+};
+
 /**
  * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct

vfio_irq_set)

include/uapi/linux/vfio.h enum { · line 569

Quoted 7 lines
include/uapi/linux/vfio.h +1 -1
  *

@@ -550,7 +566,8 @@ enum {
 	VFIO_PCI_MSIX_IRQ_INDEX,
 	VFIO_PCI_ERR_IRQ_INDEX,
 	VFIO_PCI_REQ_IRQ_INDEX,
-	VFIO_PCI_NUM_IRQS
+	VFIO_PCI_NUM_IRQS = 5	/* Fixed user ABI, IRQ indexes >=5

use */

Quoted 4 lines
include/uapi/linux/vfio.h +1 -0
+				/* device specific cap to define content */
 };
 
 /*
#4 lore raw

Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

In reply to Tina Zhang

Hi,

include/uapi/linux/vfio.h struct vfio_irq_info { · line 465

Quoted 4 lines
include/uapi/linux/vfio.h +4 -0
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */

Do we really need both type and subtype?

cheers,
Gerd

author
#5 lore raw

RE: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 15 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Thursday, June 27, 2019 2:20 PM
To: Zhang, Tina <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; [email protected]; Yuan, Hang <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 8 lines

Hi,

include/uapi/linux/vfio.h struct vfio_irq_info { · line 465

Quoted 4 lines
include/uapi/linux/vfio.h +4 -0
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */

Do we really need both type and subtype?

Then, if one device has several irqs, how can we identify them? Thanks.

BR,
tina

Quoted 8 lines

cheers,
Gerd

_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

#6 lore raw

Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Quoted 17 lines · Tina
Quoted 17 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Thursday, June 27, 2019 2:20 PM
To: Zhang, Tina <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; [email protected]; Yuan, Hang <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability

Hi,

Quoted 8 lines
Quoted 6 lines

include/uapi/linux/vfio.h struct vfio_irq_info { · line 465

Quoted 4 lines
include/uapi/linux/vfio.h +4 -0
+struct vfio_irq_info_cap_type {
+	struct vfio_info_cap_header header;
+	__u32 type;     /* global per bus driver */
+	__u32 subtype;  /* type specific */

Do we really need both type and subtype?

Then, if one device has several irqs, how can we identify them? Thanks.

Just assign multiple types?

cheers,
Gerd

author
#7 lore raw

RFC PATCH v3 2/4 vfio: Introduce vGPU display irq type

In reply to Tina Zhang

Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 3 +++
 1 file changed, 3 insertions(+)
include/uapi/linux/vfio.h +3 -0
index 600784acc4ac..c3e9c821a5cb 100644
@@ -465,6 +465,9 @@ struct vfio_irq_info_cap_type {
 	__u32 subtype;  /* type specific */
 };
 
+#define VFIO_IRQ_TYPE_GFX				(1)
+#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)
+
 /**
  * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
  *
Signature · 1 line
2.17.1
#8 lore raw

Re: [RFC PATCH v3 2/4] vfio: Introduce vGPU display irq type

Quoted 13 lines · Tina Zhang

Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 3 +++
 1 file changed, 3 insertions(+)
include/uapi/linux/vfio.h +0 -0
index 600784acc4ac..c3e9c821a5cb 100644

include/uapi/linux/vfio.h struct vfio_irq_info_cap_type { · line 469

Quoted 5 lines
include/uapi/linux/vfio.h +2 -0
@@ -465,6 +465,9 @@ struct vfio_irq_info_cap_type {
 	__u32 subtype;  /* type specific */
 };
 
+#define VFIO_IRQ_TYPE_GFX				(1)
+#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)

VFIO_IRQ_TYPE_GFX_VBLANK ?

cheers,
Gerd

author
#9 lore raw

RE: [RFC PATCH v3 2/4] vfio: Introduce vGPU display irq type

Quoted 31 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Thursday, June 27, 2019 2:21 PM
To: Zhang, Tina <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; [email protected]; Yuan, Hang <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 2/4] vfio: Introduce vGPU display irq type

Quoted 16 lines · Tina Zhang

Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display

Signed-off-by Tina Zhang <[email protected]>
---
 include/uapi/linux/vfio.h | 3 +++
 1 file changed, 3 insertions(+)
include/uapi/linux/vfio.h +0 -0
index 600784acc4ac..c3e9c821a5cb 100644
@@ -465,6 +465,9 @@ struct vfio_irq_info_cap_type {
 	__u32 subtype;  /* type specific */
 };
Quoted 4 lines

include/uapi/linux/vfio.h struct vfio_irq_info_cap_type { · line 469

Quoted 2 lines
include/uapi/linux/vfio.h +2 -0
+#define VFIO_IRQ_TYPE_GFX				(1)
+#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)

VFIO_IRQ_TYPE_GFX_VBLANK ?

VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ is proposed to cover all the display related events. In this version, we only use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to deliver vblank event. However, we might still want to reserve seat for other display event, like page flip event. Thanks.

BR,
Tina

Quoted 8 lines

cheers,
Gerd

_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

author
#10 lore raw

RFC PATCH v3 3/4 drm/i915/gvt: Register vGPU display vblank irq

In reply to Tina Zhang

Gvt-g emulates and injects the vGPU's display vblank interrupts in kernel space. However the dma-buf based framebuffer consumer in the user land (e.g. Qemu vfio/display) may also need to be notified by this event.

Register the display irq as VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to each vGPU, so that the display interrupt event can be delivered to userspace through eventfd.

Signed-off-by Tina Zhang <[email protected]>
---
 drivers/gpu/drm/i915/gvt/display.c   | 10 +++++--
 drivers/gpu/drm/i915/gvt/gvt.h       |  2 ++
 drivers/gpu/drm/i915/gvt/hypercall.h |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c     | 43 ++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/gvt/mpt.h       | 17 +++++++++++
 5 files changed, 71 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/gvt/display.c +8 -2
index e1c313da6c00..1a0a4ae4826e 100644
@@ -506,16 +506,22 @@ void intel_vgpu_clean_display(struct intel_vgpu *vgpu)
 int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64 resolution)
 {
 	struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
+	int ret;
 
 	intel_vgpu_init_i2c_edid(vgpu);
 
 	if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ||
 	    IS_COFFEELAKE(dev_priv))
-		return setup_virtual_dp_monitor(vgpu, PORT_D, GVT_DP_D,
+		ret = setup_virtual_dp_monitor(vgpu, PORT_D, GVT_DP_D,
 						resolution);
 	else
-		return setup_virtual_dp_monitor(vgpu, PORT_B, GVT_DP_B,
+		ret = setup_virtual_dp_monitor(vgpu, PORT_B, GVT_DP_B,
 						resolution);
+
+	if (ret == 0)
+		intel_gvt_hypervisor_register_display_irq(vgpu);
+
+	return ret;
 }
 
 /**
drivers/gpu/drm/i915/gvt/gvt.h +2 -0
index f5a328b5290a..cd29ea28d7ed 100644
@@ -201,6 +201,8 @@ struct intel_vgpu {
 		struct mdev_device *mdev;
 		struct vfio_region *region;
 		int num_regions;
+		struct vfio_irq *irq;
+		int num_irqs;
 		struct eventfd_ctx *intx_trigger;
 		struct eventfd_ctx *msi_trigger;
drivers/gpu/drm/i915/gvt/hypercall.h +1 -0
index 4862fb12778e..be33f20f3bc1 100644
@@ -68,6 +68,7 @@ struct intel_gvt_mpt {
 			     bool map);
 	int (*set_opregion)(void *vgpu);
 	int (*set_edid)(void *vgpu, int port_num);
+	int (*register_display_irq)(void *vgpu);
 	int (*get_vfio_device)(void *vgpu);
 	void (*put_vfio_device)(void *vgpu);
 	bool (*is_valid_gfn)(unsigned long handle, unsigned long gfn);
drivers/gpu/drm/i915/gvt/kvmgt.c +43 -0

67 lines not on this page · raw message

drivers/gpu/drm/i915/gvt/mpt.h +17 -0
index 0f9440128123..abf4a69920d3 100644
@@ -330,6 +330,23 @@ static inline int intel_gvt_hypervisor_set_edid(struct intel_vgpu *vgpu,
 	return intel_gvt_host.mpt->set_edid(vgpu, port_num);
 }
 
+/**
+ * intel_gvt_hypervisor_set_irq - register vgpu specific irq
+ * @vgpu: a vGPU
+ * @port_num: display port number
+ *
+ * Returns:
+ * Zero on success, negative error code if failed.
+ */
+static inline int intel_gvt_hypervisor_register_display_irq(
+						struct intel_vgpu *vgpu)
+{
+	if (!intel_gvt_host.mpt->register_display_irq)
+		return 0;
+
+	return intel_gvt_host.mpt->register_display_irq(vgpu);
+}
+
 /**
  * intel_gvt_hypervisor_get_vfio_device - increase vfio device ref count
  * @vgpu: a vGPU
Signature · 1 line
2.17.1
author
#11 lore raw

RFC PATCH v3 4/4 drm/i915/gvt: Deliver vGPU vblank event to userspace

In reply to Tina Zhang

Deliver the display vblank event to the user land. Userspace can use the irq mask/unmask mechanism to disable or enable the event delivery.

Signed-off-by Tina Zhang <[email protected]>
---
 drivers/gpu/drm/i915/gvt/display.c |   4 +
 drivers/gpu/drm/i915/gvt/gvt.h     |   4 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 150 +++++++++++++++++++++++++++--
 3 files changed, 149 insertions(+), 9 deletions(-)
drivers/gpu/drm/i915/gvt/display.c +4 -0
index 1a0a4ae4826e..e62313b5f8a6 100644
@@ -412,6 +412,10 @@ static void emulate_vblank_on_pipe(struct intel_vgpu *vgpu, int pipe)
 
 	if (pipe_is_enabled(vgpu, pipe)) {
 		vgpu_vreg_t(vgpu, PIPE_FRMCOUNT_G4X(pipe))++;
+		if (vgpu->vdev.vblank_trigger &&
+		    !(vgpu->vdev.display_event_mask & DISPLAY_VBLANK_EVENT))
+			eventfd_signal(vgpu->vdev.vblank_trigger, 1);
+
 		intel_vgpu_trigger_virtual_event(vgpu, vblank_event[pipe]);
 	}
 }
drivers/gpu/drm/i915/gvt/gvt.h +4 -0
index cd29ea28d7ed..b3b476ee5acf 100644
@@ -165,6 +165,8 @@ struct intel_vgpu_submission {
 	bool active;
 };
 
+#define DISPLAY_VBLANK_EVENT	(1 << 0)
+
 struct intel_vgpu {
 	struct intel_gvt *gvt;
 	struct mutex vgpu_lock;

@@ -205,6 +207,8 @@ struct intel_vgpu {
 		int num_irqs;
 		struct eventfd_ctx *intx_trigger;
 		struct eventfd_ctx *msi_trigger;
+		struct eventfd_ctx *vblank_trigger;
+		u32 display_event_mask;
 
 		/*
 		 * Two caches are used to avoid mapping duplicated pages (eg.
drivers/gpu/drm/i915/gvt/kvmgt.c +141 -9

206 lines not on this page · raw message

Signature · 1 line
2.17.1
#12 lore raw
In reply to Tina Zhang

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

cheers,
Gerd

author
#13 lore raw
Quoted 23 lines

-----Original Message-----
From: Gerd Hoffmann [mailto:[email protected]]
Sent: Thursday, June 27, 2019 2:23 PM
To: Zhang, Tina <[email protected]>
Cc: [email protected]; [email protected]; linux- [email protected]; [email protected]; Lv, Zhiyuan <[email protected]>; Wang, Zhi A <[email protected]>; Tian, Kevin <[email protected]>; Yuan, Hang <[email protected]>; [email protected]
Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

Quoted 4 lines

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. Does it make sense to vfio/display?
Thanks.

BR,
Tina

Quoted 3 lines

cheers,
Gerd

#14 lore raw
Quoted 9 lines
Quoted 9 lines

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

Quoted 6 lines
Quoted 4 lines

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

cheers,
Gerd

#15 lore raw
Quoted 21 lines · Gerd Hoffmann
Quoted 9 lines
Quoted 9 lines

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

Quoted 6 lines
Quoted 4 lines

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

Quoted 5 lines

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes? Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
#16 lore raw
Quoted 28 lines · Zhenyu Wang
Quoted 21 lines · Gerd Hoffmann
Quoted 9 lines
Quoted 9 lines

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

Quoted 6 lines
Quoted 4 lines

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

Quoted 5 lines

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

Quoted 4 lines

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes?

I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both.

Quoted 10 lines

Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

I think it should be "display update notification", i.e. userspace should check for plane changes and update the display.

Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an implementation detail though.

cheers,
Gerd

#17 lore raw
Quoted 29 lines · Gerd Hoffmann
Quoted 28 lines · Zhenyu Wang
Quoted 26 lines · Gerd Hoffmann
Quoted 9 lines
Quoted 9 lines

Hi,

Quoted 7 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one framebuffer for both drawing and display. In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

Quoted 6 lines
Quoted 4 lines

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS disable the pipe. Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

Quoted 8 lines
Quoted 4 lines

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes?

I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both.

Agree. It's more of a userspace choice.

Quoted 12 lines
Quoted 11 lines

Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

Quoted 7 lines

I think it should be "display update notification", i.e. userspace should check for plane changes and update the display.

Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an implementation detail though.

Yeah, vblank should be a good time, although driver might also do optimization e.g checking actual plane change between vblank to see if there's any real change, etc. Also that will depend on driver implementation.

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
author
#18 lore raw
In reply to Gerd Hoffmann
Quoted 66 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Friday, June 28, 2019 1:44 PM
To: Zhenyu Wang <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; Zhang, Tina <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; Yuan, Hang <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Quoted 8 lines · Zhenyu Wang
Quoted 7 lines · Gerd Hoffmann
Quoted 7 lines
Quoted 7 lines

Hi,

Quoted 5 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for mitigation. Besides, there are some cases that guest app only uses one

framebuffer for both drawing and display.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS

disable the pipe.

Quoted 13 lines
Quoted 7 lines
Quoted 1 line

Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

Quoted 5 lines

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

Quoted 3 lines

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes?

I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both.

Quoted 10 lines

Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

Quoted 5 lines

I think it should be "display update notification", i.e. userspace should check for plane changes and update the display.

Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an

Yes.

Quoted 1 line

implementation detail though.

We have two WIP branches: one is for vblank event delivery and the other one is for page flip event delivery. Repo:
- QEMU: https://github.com/intel/Igvtg-qemu.git
- Kernel: https://github.com/intel/gvt-linux.git
Two branches: topic/userspace_direct_flip_page_event and topic/userspace_direct_flip_vblank_event

With GTK UI, the user experience is bad on branch topic/userspace_direct_flip_page_event, as most of the CPU efforts are spent on event handling in user space. However, with the DRM UI both of the two branches have good user experience, as the event handling in DRM UI is pretty simple.

Thanks.

BR,
Tina

Quoted 8 lines

cheers,
Gerd

_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

author
#19 lore raw
In reply to Gerd Hoffmann

Hi,

How about GVT-g supports both vblank and page flip events. Then QEMU UI can mask/unmask the events to decide which kind of event is expected.
For DRM UI, it can decide to mask vblank event and use page flip events. We tried DRM UI with page flip events, the performance is great, even in the case of front buffer rendering. For the UI like GTK, vblank event is better.

Besides, with the irq mask/unmask mechanism, userspace can dynamically choose between the UI timer and the events.

Thanks.

BR,
Tina

Quoted 117 lines

-----Original Message-----
From: Zhang, Tina
Sent: Friday, June 28, 2019 4:45 PM
To: 'Gerd Hoffmann' <[email protected]>; Zhenyu Wang <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; [email protected]; Lv, Zhiyuan <[email protected]>; Yuan, Hang <[email protected]>; intel-gvt- [email protected]; Wang, Zhi A <[email protected]>
Subject: RE: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Quoted 14 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Friday, June 28, 2019 1:44 PM
To: Zhenyu Wang <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; Zhang, Tina <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; Yuan, Hang <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Quoted 8 lines
Quoted 7 lines · Zhenyu Wang
Quoted 6 lines · Gerd Hoffmann
Quoted 6 lines
Quoted 6 lines

Hi,

Quoted 4 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for

mitigation.

Quoted 44 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Besides, there are some cases that guest app only uses one

framebuffer for both drawing and display.

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines

In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS

disable the pipe.

Quoted 13 lines
Quoted 7 lines
Quoted 1 line

Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

Quoted 5 lines

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

Quoted 3 lines

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes?

I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both.

Quoted 10 lines

Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

Quoted 6 lines

I think it should be "display update notification", i.e. userspace should check for plane changes and update the display.

Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an

Yes.

Quoted 1 line

implementation detail though.

We have two WIP branches: one is for vblank event delivery and the other one is for page flip event delivery.
Repo:
- QEMU: https://github.com/intel/Igvtg-qemu.git
- Kernel: https://github.com/intel/gvt-linux.git
Two branches: topic/userspace_direct_flip_page_event and topic/userspace_direct_flip_vblank_event

With GTK UI, the user experience is bad on branch topic/userspace_direct_flip_page_event, as most of the CPU efforts are spent on event handling in user space.
However, with the DRM UI both of the two branches have good user experience, as the event handling in DRM UI is pretty simple.

Thanks.

BR,
Tina

Quoted 8 lines

cheers,
Gerd

_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

#20 lore raw
Quoted 7 lines · Tina

Hi,

How about GVT-g supports both vblank and page flip events. Then QEMU UI can mask/unmask the events to decide which kind of event is expected.
For DRM UI, it can decide to mask vblank event and use page flip events. We tried DRM UI with page flip events, the performance is great, even in the case of front buffer rendering. For the UI like GTK, vblank event is better.

Besides, with the irq mask/unmask mechanism, userspace can dynamically choose between the UI timer and the events.

The idea is to deliver an event to tell userspace that "guest has display update, you need to refresh your UI". How driver implementation uses either vblank or page flip to determine that is driver specific, as same routine of vfio gfx interface will be used to refresh on guest display.

If userspace doesn't set irq for vfio gfx display, it would just use own timer.

Quoted 118 lines
Quoted 118 lines

-----Original Message-----
From: Zhang, Tina
Sent: Friday, June 28, 2019 4:45 PM
To: 'Gerd Hoffmann' <[email protected]>; Zhenyu Wang <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; [email protected]; Lv, Zhiyuan <[email protected]>; Yuan, Hang <[email protected]>; intel-gvt- [email protected]; Wang, Zhi A <[email protected]>
Subject: RE: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Quoted 14 lines

-----Original Message-----
From: intel-gvt-dev [mailto:[email protected]] On Behalf Of Gerd Hoffmann
Sent: Friday, June 28, 2019 1:44 PM
To: Zhenyu Wang <[email protected]>
Cc: Tian, Kevin <[email protected]>; [email protected]; linux- [email protected]; Zhang, Tina <[email protected]>; [email protected]; Lv, Zhiyuan <[email protected]>; Yuan, Hang <[email protected]>; [email protected]; Wang, Zhi A <[email protected]>
Subject: Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace

Quoted 8 lines
Quoted 7 lines · Zhenyu Wang
Quoted 6 lines · Gerd Hoffmann
Quoted 6 lines
Quoted 6 lines

Hi,

Quoted 4 lines

Instead of delivering page flip events, we choose to post display vblank event. Handling page flip events for both primary plane and cursor plane may make user space quite busy, although we have the mask/unmask mechansim for

mitigation.

Quoted 44 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Besides, there are some cases that guest app only uses one

framebuffer for both drawing and display.

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines

In such case, guest OS won't do the plane page flip when the framebuffer is updated, thus the user land won't be notified about the

updated framebuffer.

What happens when the guest is idle and doesn't draw anything to the framebuffer?

The vblank event will be delivered to userspace as well, unless guest OS

disable the pipe.

Quoted 13 lines
Quoted 7 lines
Quoted 1 line

Does it make sense to vfio/display?

Getting notified only in case there are actual display updates would be a nice optimization, assuming the hardware is able to do that. If the guest pageflips this is obviously trivial. Not sure this is possible in case the guest renders directly to the frontbuffer.

Quoted 5 lines

What exactly happens when the guest OS disables the pipe? Is a vblank event delivered at least once? That would be very useful because it will be possible for userspace to stop polling altogether without missing the "guest disabled pipe" event.

Quoted 3 lines

It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes?

I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both.

Quoted 10 lines

Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc.

I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too.

Quoted 6 lines

I think it should be "display update notification", i.e. userspace should check for plane changes and update the display.

Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an

Yes.

Quoted 1 line

implementation detail though.

We have two WIP branches: one is for vblank event delivery and the other one is for page flip event delivery.
Repo:
- QEMU: https://github.com/intel/Igvtg-qemu.git
- Kernel: https://github.com/intel/gvt-linux.git
Two branches: topic/userspace_direct_flip_page_event and topic/userspace_direct_flip_vblank_event

With GTK UI, the user experience is bad on branch topic/userspace_direct_flip_page_event, as most of the CPU efforts are spent on event handling in user space.
However, with the DRM UI both of the two branches have good user experience, as the event handling in DRM UI is pretty simple.

Thanks.

BR,
Tina

Quoted 8 lines

cheers,
Gerd

_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827