linux-kernel - Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 May 2016 08:18:20 +0200
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	dri-devel <dri-devel@...ts.freedesktop.org>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:VIRTIO GPU DRIVER" 
	<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support

  Hi,

> > https://lists.freedesktop.org/archives/dri-devel/2016-May/108772.html
> 
> Hm, smells more like virtio isn't too happy with the default ordering of
> the commit operation. The default is:
> 
> - Disable any crtc/encoders that need to be disabled/change.
> - Bash new plane setup into hw.
> - Enable all crtcs/encoders that need to be enabled/have changed.
> 
> There's two problems:
> - some hw gets real grumpy if you bash in plane state without the crtc
>   state yet matching.
> - if you do runtime pm nothing is enabled and the writes get lost at best,
>   or hang your interconnect at worst.
> 
> That's why you can overwrite atomic_commit_tail, and use something more
> sensible. See for example what it looks like for rockchip. I have a gut
> feeling that should also take care of your troubles. Using the old crtc is
> definitely not what you want.

> Another option is that virtio isn't happy about bashing in plane state for
> disabled crtc. Again helpers have you covered, look at the active_only
> parameter for drm_atomic_helper_commit_planes().

virtio-gpu is a bit simplified compared to real hardware, so there isn't
really separate plane/crtc state.

Right now the virtual outputs are linked to drm_crtc.  To apply any
changes I need to lookup the crtc to figure which virtual output should
be updated.

So, setting active_only should make sure I have a valid crtc pointer on
plane updates, right?  It probably also skips the disable + enable crtc
steps on commit?  What happens when outputs are disabled?

Maybe it makes sense to link our virtual outputs to (primary) planes not
crtcs?

cheers,
  Gerd