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

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: <479FE157.6080606@redhat.com>
Date:	Tue, 29 Jan 2008 21:30:47 -0500
From:	Tony Camuso <tcamuso@...hat.com>
To:	Matthew Wilcox <matthew@....cx>
CC:	Arjan van de Ven <arjan@...radead.org>, Greg KH <greg@...ah.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Loic Prylli <loic@...i.com>, Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Jeff Garzik <jeff@...zik.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, Martin Mares <mj@....cz>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in

Matthew Wilcox wrote:
> On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
>>> Right now, that isn't a lot of people in x86 land, but your patch
>>> encumbers drivers for non-x86 archs with an additional call to access
>>> space that they've never had a problem with.
>> lets say s/x86/x86, IA64 and architectures that use intel, amd or via chipsets/
> 
> Umm .. ia64 already does exactly what I'm proposing for x86.  It uses
> one SAL interface for bytes below 256 and a different SAL interface for
> bytes 256-4095.
> 

Not exactly.
:)

The interface is the same, ia64_sal_pci_config_write() and ia64_sal_pci_config_read(),
but a flag bit in the mode argument is used to tell the SAL interface whether to
translate the offset component of the config address as having 8 or 12 bits of
of displacement.

In my estimation, Ivan's patch, in his implementation of Loic's suggestion, is even
more elegant, since there is no need to flag whether the access is for offsets below
256. Ivan's code automatically uses Port IO (or equivalent with Matthew's patch) for
offsets below 256 and MMCONFIG for offsets from 256 to 4096.

And even better, it removes the bitmap that tracks MMCONFIG-unfriendly devices for
the first 16 buses, a solution that assumes systems with bus numbers higher than 16
will get MMCONFIG right, which turned out to be a very wrong assumption. Furthermore,
the config address is translated by the Northbridge. The delivery mechanism to
the Northbridge, whether Port IO or MMCONFIG, is utterly opaque to the devices on the
bus, since all they see is PCI config cycles, not Port IO or MMCONFIG cycles. The test
only needed to be made at the Northbridge level, not at the device level. Ivan's patch
removes all this cruft.
--
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/