Re: PAT status?

[Daniel J Blueman]

On 30 Nov 2005 14:58:20 -0700, Andi Kleen <ak@xxxxxxx> wrote:
> Daniel J Blueman <daniel.blueman@xxxxxxxxx> writes:
>
> > IIRC, the kernel (c. 2.6.14) still does nothing to setup the
> > processors' PAT registers to enable write combining in one of the
> > slots - the defaults the BIOS establishes do not cover this. Once this
> > is done, drivers would readily be able to set page flags for a
> > particular PAT slot, and MTRRs can (almost) be safely ignored.
>
> As usual when something hasn't been done yet it's not that easy...
>
> Problem is that they would very likely create very subtle problems
> by creating conflicting mappings with the different cache attributes,
> which leads to cache corruption and other nasty issues.
>
> That is why more infrastructure is needed in the kernel to do this
> properly.

The steps I see that are needed are:

1. on initialisation, the kernel would select one PAT slot to setup
with the (eg) write combining attribute (and other slots for other
attrs)

2. expose an interface to the drivers to set the appropriate bit in a
page (range), based on searching the PAT slots, or using a known one

Intel document [1, section 10] that the uncacheable setting from PAT
or MTRR mechanisms takes precedence over the other mechanism, so the
situation will always be 'safe' (ie w/o cache corruption), and that
write-combining takes precedence over write-through or write-back MTRR
regions.

There are implementations that setup the PAT registers in userland or
in-driver and use the appropriate page flags to refer to the correct
PAT slot.

Daniel

--- [1]

ftp://download.intel.com/design/Pentium4/manuals/25366817.pdf
___
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/