linux-kernel - [PATCH 0/2] PAT support for i386 and x86

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-next>] [day] [month] [year] [list]

Message-ID: <f56c1ba00708061903r29baea3dj6b57032be5820983@mail.gmail.com>
Date:	Mon, 6 Aug 2007 22:03:15 -0400
From:	"Cédric Augonnet" <cedric.augonnet@...il.com>
To:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>, "Andi Kleen" <andi@...stfloor.org>
Cc:	loic@...i.com, brice@...i.com, cedric.augonnet@...-lyon.org
Subject: [PATCH 0/2] PAT support for i386 and x86_64

Hi all,

For quite a while now, there as been numerous attempt to introduce support for
Page Attribute Table (PAT) in the Linux kernel, whereas most other OS already
have some support for this feature. Such a proposition popping up periodically,
perhaps it would be an opportunity to fix that lack for once.

  PAT actually makes life much easier for people needing to use write-combining
(WC) attribute. Indeed the only solution yet available is MTRRs, which are not
as flexible as PAT is.
  Indeed, even if they both allow to set memory types on memory regions, MTRRs
are intended to be used on a physical memory range, while PAT makes possible
to set such memory type based on a linear address mapping. The actual problem
with MTRR is that the BIOS usually covers physical RAM with write-back (WB),
and that MTRRs should not be overlapped.
  Using write-combining feature is sometimes crucial for performance of driver
for which writes operation on the bus are critical. High-speed networking
drivers such as myri10ge would take benefit of using PAT instead of MTRRs.
Video drivers using frame-buffers could also avoid using MTRRs that way.

  PAT6 can be a candidate for that purpose. Not only for backward compatibility
reasons, but also as various errata concerning PAT would end up by having the
PAT bit ignored, therefore if we use PAT6, when such an error occurs we would
have an uncached area, which means it would at worst not be effective, thus
resolving the issues raised in http://lkml.org/lkml/2004/4/13/102 .

 *******

 Back to 2.4.20, Terence Ripperda already submitted such a proposal for PAT
 support in
   - http://lkml.org/lkml/2003/5/20/131
 himself refering to
   - http://www.ussg.iu.edu/hypermail/linux/kernel/0303.1/0606.html

 In 2005, Eric W. Biederman submitted another similar patch :
   - http://lkml.org/lkml/2005/8/29/226

 More recently, there have been numerous threads dealing with MTRR issues,
 some of them suggesting that there should actually be some support for PAT.
 See for instance :
   - http://lkml.org/lkml/2007/6/6/333

 *******

 I therefore propose here a set of 2 patches to add some support for
 write-combining using PAT :

 [PATCH 1/2] - [PAT] Setting write combining on PAT6 at boot time
 [PATCH 2/2] - [PAT] Support for write combining in pci_mmap_page_range

Kind regards,
Cedric
-
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/