KVM Archive on lore.kernel.org
 help / color / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Zhang, Tina" <tina.zhang@intel.com>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Yuan, Hang" <hang.yuan@intel.com>
Subject: RE: [PATCH v5 0/6] Deliver vGPU display refresh event to userspace
Date: Tue, 3 Sep 2019 07:43:17 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D560E0C@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <237F54289DF84E4997F34151298ABEBC8771E7AE@SHSMSX101.ccr.corp.intel.com>

> From: Zhang, Tina
> Sent: Tuesday, September 3, 2019 9:27 AM
> Hi,
> Some people are asking whether the display refresh irq could be provided by
> qemu vfio display?
> Some background: currently, we have two display timers. One is provided by
> QEMU UI and the other one is provided by the vgpu. The vgpu display
> framebuffer consumers (i.e. QEMU UIs) depend on the UI timer to consume
> the contents in the vgpu display framebuffer, meanwhile the display
> framebuffer producer (e.g. gvt-g display model) updates the framebuffer
> content according to the vblank timer provided by gpu vendor driver. Since
> these two timers are not synced, tearing could be noticed.
> So, theoretically to solve this tearing problem, we could have two options:
> Option 1: Like what we have in this patch set: stop the QEMU UI timer and let
> both the framebuffer consumers and the framebuffer producer sync to the
> display refresh event provided by vendor driver. So, QEMU UI can do the
> refresh depending on this display refresh event to make sure to have a tear-
> free framebuffer.
> Option 2: QEMU provides the emulated display refresh event to the vgpus
> provided by vendor driver. For vgpus, the display refresh event can be
> considered as the vblank event which is leveraged by guest window manager
> to do the plane update or mode-setting.
> People are asking if option 2 could be a better choice.

I think the answer is specific to different usages. None is perfect in all
scenarios. The key is to find out who is the primary display to show the 
guest framebuffer, then that guy is cared about tearing thus should be 
the source of vblank event:

1) Guest framebuffer is directly programmed to, and shown in the local
display. In such case, the physical vblank event should be the source of
virtual vblank event, i.e. kernel GVT-g driver should emulate the event
in host vblank event handler.

2) Guest framebuffer is shown in the Qemu UI. Then, naturally Qemu UI
should be the source of virtual vblank event, based on its own tearing

	a) Guest framebuffer is shown in the local application window,
which is updated by the Qemu UI timer. Then virtual vblank should be
sent at end of the UI timer handler, to make sure no change happened
when the guest framebuffer is composited as the source texture.

	b) Qemu UI may program guest framebuffer directly to the
physical plane, through whatever interface that kernel gfx driver provides.
In such case, Qemu UI should wait for vblank notification from kernel, 
and then trigger the virtual vblank event.

	c) Qemu UI may further route the guest framebuffer to remote
client, e.g. through vnc. Then virtual vblank event should be emulated
according to tearing requirement in vnc protocol.

3) combination of 1) and 2), where either local display or Qemu UI is
considered as primary display with the other for diagnostic purpose.
Then the tearing of the primary display should drive the emulation of
virtual vblank, while the other one may suffer from tearing issue.

Accordingly, we may want a kernel interface allowing user space
to specify the source of vblank emulation: in kernel or from user
space. If the former is specified, then virtual vblank is driven by 
physical vblank event. Otherwise, user space should trigger the
virtual vblank injection. Just leave all the decisions to user space. :-)


  reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  2:35 Tina Zhang
2019-08-16  2:35 ` [PATCH v5 1/6] vfio: Define device specific irq type capability Tina Zhang
2019-08-16 20:51   ` Alex Williamson
2019-08-20  0:56     ` Zhang, Tina
2019-08-16  2:35 ` [PATCH v5 2/6] vfio: Introduce vGPU display irq type Tina Zhang
2019-08-16 20:51   ` Alex Williamson
2019-08-20  2:12     ` Zhang, Tina
2019-08-20  7:20       ` kraxel
2019-08-20 15:03         ` Alex Williamson
2019-08-20 15:32       ` Alex Williamson
2019-08-16  2:35 ` [PATCH v5 3/6] drm/i915/gvt: Register vGPU display event irq Tina Zhang
2019-08-16  2:35 ` [PATCH v5 4/6] drm/i915/gvt: Deliver vGPU refresh event to userspace Tina Zhang
2019-08-26  7:55   ` Zhenyu Wang
2019-08-28  1:49     ` Tian, Kevin
2019-08-28  6:59       ` Zhang, Tina
2019-08-28  7:10         ` Tian, Kevin
2019-08-28  7:39           ` Zhang, Tina
2019-08-16  2:35 ` [PATCH v5 5/6] drm/i915/gvt: Deliver async primary plane page flip events at vblank Tina Zhang
2019-08-16  2:35 ` [PATCH v5 6/6] drm/i915/gvt: Add cursor plane reg update trap emulation handler Tina Zhang
2019-09-03  1:26 ` [PATCH v5 0/6] Deliver vGPU display refresh event to userspace Zhang, Tina
2019-09-03  7:43   ` Tian, Kevin [this message]
2019-09-05  7:48   ` kraxel
2019-09-17  9:27     ` Zhang, Tina

Reply instructions:

You may reply publically 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:

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

  git send-email \
    --in-reply-to=AADFC41AFE54684AB9EE6CBC0274A5D19D560E0C@SHSMSX104.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=hang.yuan@intel.com \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tina.zhang@intel.com \
    --cc=zhiyuan.lv@intel.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git