linux-kernel - Re: Stupid NVIDIA 3D vgaarb.c patch

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:	Fri, 26 Sep 2014 17:13:14 -0400
From:	Ilia Mirkin <imirkin@...m.mit.edu>
To:	Aaron Plattner <aplattner@...dia.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	C Bergström <cbergstrom@...hscale.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	DRI <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Stupid NVIDIA 3D vgaarb.c patch

On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner <aplattner@...dia.com> wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>>> appropriate, but hopefully somebody does. The fact that it makes
>>> things work certainly argues fairly convincingly for it, but I want
>>> some backup here.
>>>
>>> Dave, BenH?
>>>
>>> Christopher(?), can you please also specify which laptop etc. And the
>>> patch itself seems to have come from somebody else, unless you're
>>> Lekensteyn. So we'd want to get the provenance of that too.
>>
>>
>> Hrm, that sucks. "3D" could mean anything really, we might need an
>> explicit vendor ID check as well and maybe even device ID ...
>
>
> If my understanding is correct, the board designers explicitly mark them as
> "3D controller" when they don't have any outputs connected, specifically so
> the SBIOS won't choose them as the boot VGA device. Depending on the design,
> some GPUs on these 3D controller boards don't have a display engine at all,
> while others still have it in the silicon but leave it disabled at runtime.
> In either case, VGA should not be routed to them and I don't think they
> should need to participate in VGA arbitration.

Without commenting on the vga aspects of this discussion (about which
I know next to nothing), I'm moderately sure the nouveau team has seen
optimus setups where the secondary GPU reports itself as a 3d
controller, but has a working display engine, and outputs connected to
it. And I believe the inverse has also happened (a device that reports
itself as VGA but has no outputs advertised and a potentially-absent
display engine).

  -ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/