linux-kernel - Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

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]

Date:	Thu, 20 Dec 2007 15:17:22 -0500
From:	Tony Camuso <tcamuso@...hat.com>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
CC:	Matthew Wilcox <matthew@....cx>, Loic Prylli <loic@...i.com>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

Ivan Kokshaysky wrote:
> On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
>> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
>>> Does anybody see a down side to this?
>> It'll be slower than it would be if we used mmconfig directly.  Now yes,
>> nobody should be using pci config space in performance critical paths
>> ... but see the tg3 driver.
> 
> Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
> is to avoid touching BARs with mmconfig.
> 
> Ivan.

Sounds good to me.

However, this does add another in-line test for every pci config access.

The existing test is a lookup in the unreachable_devices bitmap. Even though
the bitmap only covers the first 16 buses, the lookup is performed for every
pci config access.

We would be adding another test,

   if the offset is less than 64 bytes, use legacy pci config
   else use mmconfig

The emitted code would probably only produce one branch, so it shouldn't
present a performance degradation.

Any objections to taking this tact?
--
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/