linux-kernel - Re: drm: Asynchronouse page flipping interface and Intel implementation

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]

Message-ID: <86fvv53tkt.fsf@miki.keithp.com>
Date:	Tue, 23 Jul 2013 13:33:06 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	linux-kernel@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.freedesktop.org
Subject: Re: drm: Asynchronouse page flipping interface and Intel implementation

Daniel Vetter <daniel@...ll.ch> writes:

> Quick comments on the i915 kernel part:
> - Iirc the w/a database has a bunch of entries about async flips. Those
>   need to be addressed and annoted with the new w/a tag comment format
>   Damien recently created.

Where does this database live?

> - kms_flip needs to be extended to beat on async flips. Obviously the
>   timing checks don't apply but otherwise I think it won't hurt to enable
>   all the existing interaction tests with async flips, too. On top of that
>   I think we should test interactions between async flips and vblank
>   synced flips. Without the timing checks the other tests will run as fast
>   as possible, so that should gives us good coverage of the
>   non-ratelimited nature of async flips - even with vblank flips we've hit
>   ugly issues by e.g. starving the unpin workers.

async flips are still somewhat rate-limited -- the actual buffer flip
happens on a scanline boundary instead of a frame boundary, so we still
take an interrupt and report an event back to user mode. There are
worrying comments in the bspec which say that an async flip queued
during vblank may actually take a couple of scanlines *past* the vblank
interval before it takes effect. Because of the delay, the code path
differences between the two cases are limited to just setting the bits
in the hardware, which leaves me fairly confident in our ability to test
both cases successfully.

> Oh and my little comment about moving all checks into core code is a bit
> wrong, we'd still need to check for X-tiling with async flips ofc.

From my reading, non-async flips do not have the stride and tiling mode
requirements which are currently in the code though. Might be nice to
test this?

-- 
keith.packard@...el.com

Content of type "application/pgp-signature" skipped