Re: PAT support for i386 and x86_64

[Daniel J Blueman]

On 7 Aug, 09:40, Andi Kleen <a...@xxxxxxxxxxxxxx> wrote:
> On Mon, Aug 06, 2007 at 10:03:15PM -0400, Cédric Augonnet wrote:
> > 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.
>
> The trouble is you need to avoid conflicting attributes, otherwise
> you risk cache corruption. This means the direct mapping needs to be fixed
> up and the kernel needs to keep track of the ranges to prevent conflicts.

The general case of drivers setting up mappings to PCI memory space is
usually done consistently, thus no virtual pages with different PAT
indexes referring to the same physical page would exist here.

What cases did you have in mind?

> Also when there is already a MTRR it might not work due to the complicated
> rules of MTRR<->PAT interaction.

Not so complicated - stronger ordering always takes precedence (for safety).

>From current Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide, section 10.5.2:

"[...] If there is an overlap of page-level and MTRR caching controls,
the mechanism that prevents caching has precedence. In cases where
there is a overlap in the assignment of the write-back and
write-through caching policies to a page and a region of memory, the
write-through policy takes precedence. The write-combining policy
(which can only be assigned through an MTRR or the PAT) takes
precedence over either write-through or write-back."

If (eg) a broken BIOS marks PCI memory space as UC, we gain nothing
like today. Most modern systems (in the server domain) I've seen don't
do this, as Windows' use of PAT would be broken too.

> Then there are old CPU errata that need to be handled etc.

I don't see a problem with having CONFIG_PAT depend on P4/Athlon or
newer to avoid such workarounds for now. Better to have something
there which works in (only) 80% of the cases, than nothing at all.

> There are also some other issues.

What like?

> You didn't solve all that at all. If it was as simple as your patch
> we would have long done it already.

Perhaps this feature can be marked as WIP to allow this to move
forward while corner-cases are worked out. Adding such a go/no-go
barrier will hamper progress we do see, as it has done already for
years.

The PCI ordering config option years ago was a similar case, since
various drivers didn't issue wmb()s until they were fixed up.

Daniel
--
Daniel J Blueman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/