linux-kernel - Re: [PATCH]PCI:disable resource decode in PCI BAR detection

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]

Message-Id: <200709191434.45127.jbarnes@virtuousgeek.org>
Date:	Wed, 19 Sep 2007 14:34:44 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Shaohua Li <shaohua.li@...el.com>,
	Robert Hancock <hancockr@...w.ca>, Greg KH <gregkh@...e.de>,
	Matthew Wilcox <matthew@....cx>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Tuesday, September 18, 2007 2:53 am Ivan Kokshaysky wrote:
> On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote:
> > I can confirm this is an add-in graphics card. the bfd is 00:02.0,
> > so it's not behind any AGP/PCI-E bridge.
>
> AFAIKS, 00:02.0 is *integrated* controller. Can you check that
> "graphic adapter priority" setting in BIOS is "PCI Express" and not
> "Internal VGA"? In the latter case an add-on card might be turned
> completely off, so it doesn't even show up in lspci output.

Yeah, it's integrated gfx.  See the PRM at intel.com for the decode 
rules.

I've been following this thread and I see a lot of fear about moving to 
probing BARs as outlined in the PCI spec.  I haven't seen much in the 
way of hard evidence though, mostly just handwaving or red herrings 
(and even one comment implying that -mm wasn't a real testbed for 
patches) that don't have much to do with the actual "disable, size, 
re-enable" logic.  Has a conclusion been reached yet?

Keep in mind that any failures that occur due to this patch should be 
easy to track down (boot hang), but we have yet to see any in real 
life.  Moreover, reversion is trivial, and we could move to a more 
complex scheme at that time if needed, but why bother unless we're sure 
we need to?

Thanks,
Jesse
-
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/