linux-kernel - Re: [git pull] drm fixes + one missed next for 5.16-rc1

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] [day] [month] [year] [list]

Date:   Mon, 15 Nov 2021 15:29:28 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Airlie <airlied@...il.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Ashutosh Dixit <ashutosh.dixit@...el.com>,
        Matthew Auld <matthew.auld@...el.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Subject: Re: [git pull] drm fixes + one missed next for 5.16-rc1

On Mon, Nov 15, 2021 at 08:18:53AM +0100, Thomas Hellström wrote:
> On 11/14/21 22:19, Linus Torvalds wrote:
> > On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie <airlied@...il.com> wrote:
> > > i915 will no longer be x86-64 only in theory, since Intel now produces
> > > PCIe graphics cards using the same hw designs.
> > Well, at least in my tree, it still has the "depends on X86", along
> > with several other x86-only things (like "select INTEL_GTT", which is
> > also x86-only)

Yeah it's work in progress and 12+ years of x86 pile up high&deep aren't
easy to fix. So please assume the depends on X86 is gone already (and
select INTEL_GTT is optional, it's only needed for igfx older than about 8
years or so), but we can't do that yet because all the build boots would
run out of air screaming so much :-)

> > So by the time that non-x86 theory becomes reality, hopefully the i915
> > people will also have figured out how to do the cache flushing
> > properly.
> > 
> > And hopefully that "do it properly" ends up being simply that the
> > particular configuration that ends up being portable simply doesn't
> > need to do it at all and can statically just not build it,
> > sidestepping the issue entirely.
> > 
> > Fingers crossed.
> 
> For non-x86 / discrete graphics, plan is only coherent mappings, although
> the "Just not build it" part hasn't been properly figured out yet I guess.
> But point taken.

Yeah for non-x86 it'll be standard dma-api all the way down. For x86 that
ship sailed long ago, but also I'm not clear on why we added a new cache
flush primitive for that instead of just continuing to use clflush like
we've done since forever. For x86 integrated gpu we _know_ which cpu is
there, clflush will exist. So any new horrors shouldn't be needed, not
sure why a wbinvd_on_all_cpus slipped in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch