linux-kernel - Re: [PATCH] x86/gpu: add JSL stolen memory 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]

Message-ID: <20201203152520.GA1554214@bjorn-Precision-5520>
Date:   Thu, 3 Dec 2020 09:25:20 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
Cc:     "Surendrakumar Upadhyay, TejaskumarX" 
        <tejaskumarx.surendrakumar.upadhyay@...el.com>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
        "De Marchi, Lucas" <lucas.demarchi@...el.com>,
        "Roper, Matthew D" <matthew.d.roper@...el.com>,
        "Pandey, Hariom" <hariom.pandey@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...ux.ie>
Subject: Re: [PATCH] x86/gpu: add JSL stolen memory support

On Thu, Dec 03, 2020 at 10:46:29AM +0200, Joonas Lahtinen wrote:
> Quoting Bjorn Helgaas (2020-12-02 22:22:53)
> > On Wed, Dec 02, 2020 at 05:21:58AM +0000, Surendrakumar Upadhyay, TejaskumarX wrote:
> > > Yes it fails all the tests which are allocating from this stolen
> > > memory bunch. For example IGT tests like "
> > > igt@..._frontbuffer_tracking@-[fbc|fbcpsr].* |
> > > igt@..._fbcon_fbt@....* " are failing as they totally depend to work
> > > on stolen memory.
> 
> That's just because we have de-duped the stolen memory detection code.
> If it's not detected at the early quirks, it's not detected by the
> driver at all.
> 
> So if the patch is not merged to early quirks, we'd have to refactor the
> code to add alternative detection path to i915. Before that is done, the
> failures are expected.
> 
> > I'm sure that means something to graphics developers, but I have no
> > idea!  Do you have URLs for the test case source, outputs, dmesg log,
> > lspci info, bug reports, etc?
> 
> The thing is, the bug reports for stuff like this would only start to
> flow after Jasperlake systems are shipping widely and the less common
> OEMs start integrating it to into strangely behaving BIOSes. Or that
> is the assumption.
> 
> If it's fine to merge this through i915 for now with an Acked-by, like
> the previous patches, that'd be great. We can start a discussion on if
> the new platforms are affected anymore. But I'd rather not drop it
> before we have that understanding, as the previous problems have
> included boot time memory corruption.
> 
> Would that work?

Like I said, I'm not objecting if somebody else wants to apply this.

I'm just pointing out that there's a little bit of voodoo here because
it's not clear what makes a BIOS strangely behaving or what causes
boot-time memory corruption, and that means we don't really have any
hope of resolving this stream of quirk updates.

Bjorn