Deliver vGPU display vblank event to userspace
Subsystems (5)
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
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.
--- include/uapi/linux/vfio.h | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
include/uapi/linux/vfio.h +18 -1
@@ -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
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
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 */ };/*
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 capabilityQuoted 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
-0include/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 */ };/*
Re: [RFC PATCH v3 1/4] vfio: Define device specific irq type capability
In reply to Tina ZhangHi,
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
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
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 capabilityHi,
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
RFC PATCH v3 2/4 vfio: Introduce vGPU display irq type
In reply to Tina ZhangIntroduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display
--- include/uapi/linux/vfio.h | 3 +++ 1 file changed, 3 insertions(+)
include/uapi/linux/vfio.h +3 -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_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set) *
Signature · 1 line
2.17.1
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, andVFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQas the subtype for vGPU displaySigned-off-by Tina Zhang <[email protected]>--- include/uapi/linux/vfio.h | 3 +++ 1 file changed, 3 insertions(+)include/uapi/linux/vfio.h +0
-0
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
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 typeQuoted 16 lines · Tina Zhang
Introduce vGPU specific irq type
VFIO_IRQ_TYPE_GFX, andVFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQas the subtype for vGPU displaySigned-off-by Tina Zhang <[email protected]>--- include/uapi/linux/vfio.h | 3 +++ 1 file changed, 3 insertions(+)include/uapi/linux/vfio.h +0
-0@@ -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
RFC PATCH v3 3/4 drm/i915/gvt: Register vGPU display vblank irq
In reply to Tina ZhangGvt-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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
RFC PATCH v3 4/4 drm/i915/gvt: Deliver vGPU vblank event to userspace
In reply to Tina ZhangDeliver the display vblank event to the user land. Userspace can use the irq mask/unmask mechanism to disable or enable the event delivery.
--- 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
@@ -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
@@ -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
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
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 userspaceHi,
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
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
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
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
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
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 userspaceQuoted 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
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 userspaceQuoted 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 userspaceQuoted 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_eventWith 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,
TinaQuoted 8 lines
cheers,
Gerd_______________________________________________
intel-gvt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
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 userspaceQuoted 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 userspaceQuoted 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_eventWith 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,
TinaQuoted 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