diff mbox series

[v5,2/6] vfio: Introduce vGPU display irq type

Message ID 20190816023528.30210-3-tina.zhang@intel.com (mailing list archive)
State New, archived
Headers show
Series Deliver vGPU display refresh event to userspace | expand

Commit Message

Zhang, Tina Aug. 16, 2019, 2:35 a.m. UTC
Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and
VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display.

Introduce vfio_irq_info_cap_display_plane_events capability to notify
user space with the vGPU's plane update events

v2:
- Add VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ description. (Alex & Kechen)
- Introduce vfio_irq_info_cap_display_plane_events. (Gerd & Alex)

Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---
 include/uapi/linux/vfio.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Alex Williamson Aug. 16, 2019, 8:51 p.m. UTC | #1
On Fri, 16 Aug 2019 10:35:24 +0800
Tina Zhang <tina.zhang@intel.com> wrote:

> Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and
> VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display.
> 
> Introduce vfio_irq_info_cap_display_plane_events capability to notify
> user space with the vGPU's plane update events
> 
> v2:
> - Add VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ description. (Alex & Kechen)
> - Introduce vfio_irq_info_cap_display_plane_events. (Gerd & Alex)
> 
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
>  include/uapi/linux/vfio.h | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index d83c9f136a5b..21ac69f0e1a9 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -465,6 +465,27 @@ struct vfio_irq_info_cap_type {
>  	__u32 subtype;  /* type specific */
>  };
>  
> +#define VFIO_IRQ_TYPE_GFX				(1)
> +/*
> + * vGPU vendor sub-type
> + * vGPU device display related interrupts e.g. vblank/pageflip
> + */
> +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)

If this is a GFX/DISPLAY IRQ, why are we talking about a "vGPU" in the
description?  It's not specific to a vGPU implementation, right?  Is
this related to a physical display or a virtual display?  If it's
related to the GFX PLANE ioctls, it should state that.  It's not well
specified what this interrupt signals.  Is it vblank?  Is it pageflip?
Is it both?  Neither?  Something else?

> +
> +/*
> + * Display capability of using one eventfd to notify user space with the
> + * vGPU's plane update events.
> + * cur_event_val: eventfd value stands for cursor plane change event.
> + * pri_event_val: eventfd value stands for primary plane change event.
> + */
> +#define VFIO_IRQ_INFO_CAP_DISPLAY	4
> +
> +struct vfio_irq_info_cap_display_plane_events {
> +	struct vfio_info_cap_header header;
> +	__u64 cur_event_val;
> +	__u64 pri_event_val;
> +};

Again, what display?  Does this reference a GFX plane?  The event_val
data is not well specified, examples might be necessary.  They seem to
be used as a flag bit, so should we simply define a bit index for the
flag rather than a u64 value?  Where are the actual events per plane
defined?

I'm not sure this patch shouldn't be rolled back into 1, I couldn't
find the previous discussion that triggered it to be separate.  Perhaps
simply for sharing with the work Eric is doing?  If so, that's fine,
but maybe make note of it in the cover letter.  Thanks,

Alex
Zhang, Tina Aug. 20, 2019, 2:12 a.m. UTC | #2
> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Saturday, August 17, 2019 4:52 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: intel-gvt-dev@lists.freedesktop.org; kraxel@redhat.com;
> kvm@vger.kernel.org; linux-kernel@vger.kernel.org; Yuan, Hang
> <hang.yuan@intel.com>; Lv, Zhiyuan <zhiyuan.lv@intel.com>
> Subject: Re: [PATCH v5 2/6] vfio: Introduce vGPU display irq type
> 
> On Fri, 16 Aug 2019 10:35:24 +0800
> Tina Zhang <tina.zhang@intel.com> wrote:
> 
> > Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and
> > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display.
> >
> > Introduce vfio_irq_info_cap_display_plane_events capability to notify
> > user space with the vGPU's plane update events
> >
> > v2:
> > - Add VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ description. (Alex & Kechen)
> > - Introduce vfio_irq_info_cap_display_plane_events. (Gerd & Alex)
> >
> > Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> > ---
> >  include/uapi/linux/vfio.h | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index d83c9f136a5b..21ac69f0e1a9 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -465,6 +465,27 @@ struct vfio_irq_info_cap_type {
> >  	__u32 subtype;  /* type specific */
> >  };
> >
> > +#define VFIO_IRQ_TYPE_GFX				(1)
> > +/*
> > + * vGPU vendor sub-type
> > + * vGPU device display related interrupts e.g. vblank/pageflip  */
> > +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)
> 
> If this is a GFX/DISPLAY IRQ, why are we talking about a "vGPU" in the
> description?  It's not specific to a vGPU implementation, right?  Is this
> related to a physical display or a virtual display?  If it's related to the GFX
> PLANE ioctls, it should state that.  It's not well specified what this interrupt
> signals.  Is it vblank?  Is it pageflip?
> Is it both?  Neither?  Something else?

Sorry for the confusion caused here. 

The original idea here was to use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to notify user space with the display refresh event. The display refresh event is general. When notified, user space can use VFIO_DEVICE_QUERY_GFX_PLANE and VFIO_DEVICE_GET_GFX_DMABUF to get the updated framebuffer, instead of polling them all the time.

In order to give user space more choice to do the optimization, vfio_irq_info_cap_display_plane_events is proposed to tell user space the different plane refresh event values. So when notified by VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ, user space can get the value of the eventfd counter and understand which plane the event refresh event comes from and choose to get the framebuffer on that plane instead of all the planes.

So, from the VFIO user point of view, there is only the display refresh event (i.e. no other events like vblank, pageflip ...). For GTV-g, this display refresh event is implemented by both vblank and pageflip, which is only the implementation thing and can be transparent to the user space. Again sorry about the confusion cased here, I'll correct the comments in the next version.

BTW, IIRC, we might also have one question waiting to be replied:
- Can we just use VFIO_IRQ_TYPE_GFX w/o proposing a new sub type (i.e. VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ)?
    Well, only if we can agree on that we don't have any other GFX IRQ requirements in future. Otherwise, we might need a sub type to differentiate them.

Thanks.

BR,
Tina
> 
> > +
> > +/*
> > + * Display capability of using one eventfd to notify user space with
> > +the
> > + * vGPU's plane update events.
> > + * cur_event_val: eventfd value stands for cursor plane change event.
> > + * pri_event_val: eventfd value stands for primary plane change event.
> > + */
> > +#define VFIO_IRQ_INFO_CAP_DISPLAY	4
> > +
> > +struct vfio_irq_info_cap_display_plane_events {
> > +	struct vfio_info_cap_header header;
> > +	__u64 cur_event_val;
> > +	__u64 pri_event_val;
> > +};
> 
> Again, what display?  Does this reference a GFX plane?  The event_val data is
> not well specified, examples might be necessary.  They seem to be used as a
> flag bit, so should we simply define a bit index for the flag rather than a u64
> value?  Where are the actual events per plane defined?
> 
> I'm not sure this patch shouldn't be rolled back into 1, I couldn't find the
> previous discussion that triggered it to be separate.  Perhaps simply for
> sharing with the work Eric is doing?  If so, that's fine, but maybe make note
> of it in the cover letter.  Thanks,
> 
> Alex
Gerd Hoffmann Aug. 20, 2019, 7:20 a.m. UTC | #3
> > > +#define VFIO_IRQ_TYPE_GFX				(1)
> > > +/*
> > > + * vGPU vendor sub-type
> > > + * vGPU device display related interrupts e.g. vblank/pageflip  */
> > > +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)
> > 
> > If this is a GFX/DISPLAY IRQ, why are we talking about a "vGPU" in the
> > description?  It's not specific to a vGPU implementation, right?  Is this
> > related to a physical display or a virtual display?  If it's related to the GFX
> > PLANE ioctls, it should state that.  It's not well specified what this interrupt
> > signals.  Is it vblank?  Is it pageflip?
> > Is it both?  Neither?  Something else?
> 
> Sorry for the confusion caused here. 
> 
> The original idea here was to use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to
> notify user space with the display refresh event. The display refresh
> event is general. When notified, user space can use
> VFIO_DEVICE_QUERY_GFX_PLANE and VFIO_DEVICE_GET_GFX_DMABUF to get the
> updated framebuffer, instead of polling them all the time.
> 
> In order to give user space more choice to do the optimization,
> vfio_irq_info_cap_display_plane_events is proposed to tell user space
> the different plane refresh event values. So when notified by
> VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ, user space can get the value of the
> eventfd counter and understand which plane the event refresh event
> comes from and choose to get the framebuffer on that plane instead of
> all the planes.
> 
> So, from the VFIO user point of view, there is only the display
> refresh event (i.e. no other events like vblank, pageflip ...). For
> GTV-g, this display refresh event is implemented by both vblank and
> pageflip, which is only the implementation thing and can be
> transparent to the user space. Again sorry about the confusion cased
> here, I'll correct the comments in the next version.

All this should be explained in a comment for the IRQ in the header file.

Key point for the API is that (a) this is a "the display should be
updated" event and (b) this covers all display updates, i.e. user space
can stop the display update timer and fully depend on getting
notifications if an update is needed.

That GTV-g watches guest pageflips is an implementation detail.  Should
nvidia support this they will probably do something completely
different.  As far I know they render the guest display to some
framebuffer at something like 10fps, so it would make sense for them to
send an event each time they refreshed the framebuffer.

Also note the relationships (cur_event_val is for DRM_PLANE_TYPE_CURSOR
updates and pri_event_val for DRM_PLANE_TYPE_PRIMARY).

cheers,
  Gerd
Alex Williamson Aug. 20, 2019, 3:03 p.m. UTC | #4
On Tue, 20 Aug 2019 09:20:30 +0200
"kraxel@redhat.com" <kraxel@redhat.com> wrote:

> > > > +#define VFIO_IRQ_TYPE_GFX				(1)
> > > > +/*
> > > > + * vGPU vendor sub-type
> > > > + * vGPU device display related interrupts e.g. vblank/pageflip  */
> > > > +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)  
> > > 
> > > If this is a GFX/DISPLAY IRQ, why are we talking about a "vGPU" in the
> > > description?  It's not specific to a vGPU implementation, right?  Is this
> > > related to a physical display or a virtual display?  If it's related to the GFX
> > > PLANE ioctls, it should state that.  It's not well specified what this interrupt
> > > signals.  Is it vblank?  Is it pageflip?
> > > Is it both?  Neither?  Something else?  
> > 
> > Sorry for the confusion caused here. 
> > 
> > The original idea here was to use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to
> > notify user space with the display refresh event. The display refresh
> > event is general. When notified, user space can use
> > VFIO_DEVICE_QUERY_GFX_PLANE and VFIO_DEVICE_GET_GFX_DMABUF to get the
> > updated framebuffer, instead of polling them all the time.
> > 
> > In order to give user space more choice to do the optimization,
> > vfio_irq_info_cap_display_plane_events is proposed to tell user space
> > the different plane refresh event values. So when notified by
> > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ, user space can get the value of the
> > eventfd counter and understand which plane the event refresh event
> > comes from and choose to get the framebuffer on that plane instead of
> > all the planes.
> > 
> > So, from the VFIO user point of view, there is only the display
> > refresh event (i.e. no other events like vblank, pageflip ...). For
> > GTV-g, this display refresh event is implemented by both vblank and
> > pageflip, which is only the implementation thing and can be
> > transparent to the user space. Again sorry about the confusion cased
> > here, I'll correct the comments in the next version.  
> 
> All this should be explained in a comment for the IRQ in the header file.

Yes, Tina's update and your clarification all make sense to me, but it
needs to be specified in the header how this is supposed to work, what
events get signaled and what the user is intended to do in response to
that signal.  The information is all here, it just needs to be included
in the uapi definition.  Thanks,

Alex

> Key point for the API is that (a) this is a "the display should be
> updated" event and (b) this covers all display updates, i.e. user space
> can stop the display update timer and fully depend on getting
> notifications if an update is needed.
> 
> That GTV-g watches guest pageflips is an implementation detail.  Should
> nvidia support this they will probably do something completely
> different.  As far I know they render the guest display to some
> framebuffer at something like 10fps, so it would make sense for them to
> send an event each time they refreshed the framebuffer.
> 
> Also note the relationships (cur_event_val is for DRM_PLANE_TYPE_CURSOR
> updates and pri_event_val for DRM_PLANE_TYPE_PRIMARY).
Alex Williamson Aug. 20, 2019, 3:32 p.m. UTC | #5
On Tue, 20 Aug 2019 02:12:10 +0000
"Zhang, Tina" <tina.zhang@intel.com> wrote:

> BTW, IIRC, we might also have one question waiting to be replied:
> - Can we just use VFIO_IRQ_TYPE_GFX w/o proposing a new sub type
> (i.e. VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ)? Well, only if we can agree
> on that we don't have any other GFX IRQ requirements in future.
> Otherwise, we might need a sub type to differentiate them.

I think you've answered your own question ;)  We already have the
infrastructure for defining type/sub-type and it allows us to
categorize and group interrupt types together consistent with how we do
for regions, so what's the overhead in this approach?  Otherwise we
tend to have an ad-hoc list.  We can't say with absolute certainty that
we won't have additional GFX related IRQs.  Thanks,

Alex
diff mbox series

Patch

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index d83c9f136a5b..21ac69f0e1a9 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -465,6 +465,27 @@  struct vfio_irq_info_cap_type {
 	__u32 subtype;  /* type specific */
 };
 
+#define VFIO_IRQ_TYPE_GFX				(1)
+/*
+ * vGPU vendor sub-type
+ * vGPU device display related interrupts e.g. vblank/pageflip
+ */
+#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ		(1)
+
+/*
+ * Display capability of using one eventfd to notify user space with the
+ * vGPU's plane update events.
+ * cur_event_val: eventfd value stands for cursor plane change event.
+ * pri_event_val: eventfd value stands for primary plane change event.
+ */
+#define VFIO_IRQ_INFO_CAP_DISPLAY	4
+
+struct vfio_irq_info_cap_display_plane_events {
+	struct vfio_info_cap_header header;
+	__u64 cur_event_val;
+	__u64 pri_event_val;
+};
+
 /**
  * VFIO_DEVICE_SET_IRQS - _IOW(VFIO_TYPE, VFIO_BASE + 10, struct vfio_irq_set)
  *