linux-kernel - Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071222211026.GT29690@parisc-linux.org>
Date:	Sat, 22 Dec 2007 14:10:26 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org,
	gregkh@...e.de, linux-pci@...ey.karlin.mff.cuni.cz,
	torvalds@...ux-foundation.org
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Sat, Dec 22, 2007 at 08:02:49AM -0800, Arjan van de Ven wrote:
> even then.. it's technically not correct; you're not supposed to mix access types for the same device..
> Just doing opt-in also allows us to do quirks (forbid access) as well.

I think what this specification means is that you can't mix both _at the
same time_.  ie, doing a type 1 cycle, then before it returns, do an
mmconfig cycle.  We never try to do that because there's a spinlock to
prevent more than one config space access at a time.  It *has* to work
to do them sequentially -- for example, the BIOS may do type1 config
accesses, then the OS may do mmconfig.

I've occasionally wondered if that spinlock needs to get split up, but
for the amount of pain that could ensue, I can't imagine it ever being
worthwhile.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/