kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "kraxel@redhat.com" <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Zhang, Tina" <tina.zhang@intel.com>,
	"Lu, Kechen" <kechen.lu@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"Wang, Zhi A" <zhi.a.wang@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Yuan, Hang" <hang.yuan@intel.com>
Subject: Re: [RFC PATCH v4 2/6] vfio: Introduce vGPU display irq type
Date: Fri, 2 Aug 2019 15:35:31 +0200	[thread overview]
Message-ID: <20190802133531.4zwsjltvjisq4sfz@sirius.home.kraxel.org> (raw)
In-Reply-To: <20190722191830.425d1593@x1.home>

  Hi,

> > > Couldn't you expose this as another capability within the IRQ_INFO return
> > > data?  If you were to define it as a macro, I assume that means it would be
> > > hard coded, in which case this probably becomes an Intel specific IRQ, rather
> > > than what appears to be framed as a generic graphics IRQ extension.  A new
> > > capability could instead allow the vendor to specify their own value, where
> > > we could define how userspace should interpret and make use of this value.
> > > Thanks,  
> > Good suggestion. Currently, vfio_irq_info is used to save one irq
> > info. What we need here is to use it to save several events info.
> > Maybe we could figure out a general layout of this capability so that
> > it can be leveraged by others, not only for display irq/events.
> 
> You could also expose a device specific IRQ with count > 1 (ie. similar
> to MSI/X) and avoid munging the eventfd value, which is not something
> we do elsewhere, at least in vfio.  Thanks,

Well, the basic idea is to use the eventfd value to signal the kind of
changes which did happen, simliar to IRQ status register bits.

So, when the guest changes the primary plane, the mdev driver notes
this.  Same with the cursor plane.  On vblank (when the guests update
is actually applied) the mdev driver wakes the eventfd and uses eventfd
value to signal whenever primary plane or cursor plane or both did
change.

Then userspace knows which planes need an update without an extra
VFIO_DEVICE_QUERY_GFX_PLANE roundtrip to the kernel.

Alternatively we could have one eventfd for each change type.  But given
that these changes are typically applied at the same time (vblank) we
would have multiple eventfds being signaled at the same time.  Which
doesn't look ideal to me ...

cheers,
  Gerd


  parent reply	other threads:[~2019-08-02 13:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-18 15:56 [RFC PATCH v4 0/6] Deliver vGPU display refresh event to userspace Kechen Lu
2019-07-18 15:56 ` [RFC PATCH v4 1/6] vfio: Define device specific irq type capability Kechen Lu
2019-07-19  6:05   ` Zhenyu Wang
2019-07-19  9:02     ` Lu, Kechen
2019-07-19  9:59       ` Zhenyu Wang
2019-07-18 15:56 ` [RFC PATCH v4 2/6] vfio: Introduce vGPU display irq type Kechen Lu
2019-07-19 16:25   ` Alex Williamson
2019-07-22  5:28     ` Lu, Kechen
2019-07-22 19:41       ` Alex Williamson
2019-07-23  1:08         ` Zhang, Tina
2019-07-23  1:18           ` Alex Williamson
2019-07-23  1:54             ` Zhang, Tina
2019-08-02 13:35             ` kraxel [this message]
2019-08-02 14:38               ` Alex Williamson
2019-07-18 15:56 ` [RFC PATCH v4 3/6] drm/i915/gvt: Register vGPU display event irq Kechen Lu
2019-07-18 15:56 ` [RFC PATCH v4 4/6] drm/i915/gvt: Deliver vGPU refresh event to userspace Kechen Lu
2019-07-19  6:24   ` Zhenyu Wang
2019-07-19  9:28     ` Lu, Kechen
2019-07-18 15:56 ` [RFC PATCH v4 5/6] drm/i915/gvt: Deliver async primary plane page flip events at vblank Kechen Lu
2019-07-18 15:56 ` [RFC PATCH v4 6/6] drm/i915/gvt: Add cursor plane reg update trap emulation handler Kechen Lu
2019-07-19  6:34   ` Zhenyu Wang
2019-07-19  9:33     ` Lu, Kechen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190802133531.4zwsjltvjisq4sfz@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=hang.yuan@intel.com \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kechen.lu@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tina.zhang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.com \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).