Re: [RFC PATCH v2 1/3] vfio: Use capability chains to handle device specific irq

[Alex Williamson]

On Thu, 6 Jun 2019 10:17:51 +0000
"Zhang, Tina" <tina.zhang@xxxxxxxxx> wrote:

> > -----Original Message-----
> > From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@xxxxxxxxxxxxxxxxxxxxx] On
> > Behalf Of kraxel@xxxxxxxxxx
> > Sent: Wednesday, June 5, 2019 6:10 PM
> > To: Zhang, Tina <tina.zhang@xxxxxxxxx>
> > Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx; Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx>; Yuan,
> > Hang <hang.yuan@xxxxxxxxx>; alex.williamson@xxxxxxxxxx; Lv, Zhiyuan
> > <zhiyuan.lv@xxxxxxxxx>; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx; Wang, Zhi A
> > <zhi.a.wang@xxxxxxxxx>
> > Subject: Re: [RFC PATCH v2 1/3] vfio: Use capability chains to handle device
> > specific irq
> > 
> >   Hi,
> >   
> > > > Really need to split for different planes? I'd like a
> > > > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_EVENT
> > > > so user space can probe change for all.  
> >   
> > > User space can choose to user different handlers according to the
> > > specific event. For example, user space might not want to handle every
> > > cursor event due to performance consideration. Besides, it can reduce
> > > the probe times, as we don't need to probe twice to make sure if both
> > > cursor plane and primary plane have been updated.  
> > 
> > I'd suggest to use the value passed via eventfd for that, i.e. instead of
> > sending "1" unconditionally send a mask of changed planes.  
> If there is only one eventfd working for GFX_DISPLAY, should it be
> VFIO_IRQ_INFO_EVENTFD and VFIO_IRQ_INFO_AUTOMASKED? i.e. after
> signaling, the interrupt is automatically masked and the user space
> needs to unmask the line to receive new irq event.

If there's any way at all the interrupt is rate limited already, I'd
suggest not to use automasked.  This flag is generally intended for
cases where we need to mask a host interrupt and don't have a generic
or efficient way to determine acknowledgement of the interrupt and
therefore require an explicit unmask.  If the events here are not at a
high frequency or you can tell by other interactions that they've been
acted upon, I'd suggest to handle these as an edge triggered interrupt
w/o automasked.  Thanks,

Alex