PAT status?

PAT status?

[Jeff Garzik]

What's the status of PAT support?

I'm interested in that sort of stuff, for use with on-board GPUs such as 
Intel/VIA/SiS, where system memory is used rather than offboard ram.

	Jeff

Re: PAT status?

[Terence Ripperda]

Hi Jeff,

I unfortunately haven't had much time to look at the status of the PAT
code I had been working on. there are really 2 steps to the code:

the first is enabling and configuring the PAT registers. this then
allows a page table entry define that can be passed to traditional
interfaces, such as remap_page_range or change_page_attr. this is
pretty simple and we've been using a similar interface in our driver
for some time now.

the second part was to make sure we didn't create any cache aliasing
via duplicate mappings. this part is a bit more involved and what was
holding everything back. I've been meaning to get back to looking at
this, but really haven't had the time.

I don't know if you still want to limit the additional of the first
step, based on completion of the second step. I can try to set time
aside over the next month to try and sync up and take a look at where
we stand w/ the cachemap portion of the code. I think there where
still issues with gathering/passing in the correct attributes.

Thanks,
Terence


On Tue, Nov 29, 2005 at 05:22:37PM -0500, jgarzik@pobox.com wrote:
> 
> What's the status of PAT support?
> 
> I'm interested in that sort of stuff, for use with on-board GPUs such as 
> Intel/VIA/SiS, where system memory is used rather than offboard ram.
> 
> 	Jeff
> 
> 
> 

Re: PAT status?

[Daniel J Blueman]

Hi Jeff,

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.

Daniel
___
Daniel J Blueman

Re: PAT status?

[Andi Kleen]

Daniel J Blueman <daniel.blueman@gmail.com> 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.

-Andi

Re: PAT status?

[Daniel J Blueman]

On 30 Nov 2005 14:58:20 -0700, Andi Kleen <ak@suse.de> wrote:
> Daniel J Blueman <daniel.blueman@gmail.com> 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

Re: PAT status?

[Daniel J Blueman]

Terence Ripperda wrote:
> Hi Jeff,
>
> I unfortunately haven't had much time to look at the status of the PAT
> code I had been working on. there are really 2 steps to the code:
>
> the first is enabling and configuring the PAT registers. this then
> allows a page table entry define that can be passed to traditional
> interfaces, such as remap_page_range or change_page_attr. this is
> pretty simple and we've been using a similar interface in our driver
> for some time now.
>
> the second part was to make sure we didn't create any cache aliasing
> via duplicate mappings. this part is a bit more involved and what was
> holding everything back. I've been meaning to get back to looking at
> this, but really haven't had the time.

If you mean aliasing by the way of having MTRR entries conflicting
with PAT page flags, then is this better dealt with by in-kernel
drivers being changed to use PAT rather than the MTRR interface? One
day, the kernel MTRR interface will be deprecated and unusable
(modules could still program the MTRRs as PAT is done today in a
number of drivers).

> I don't know if you still want to limit the additional of the first
> step, based on completion of the second step. I can try to set time
> aside over the next month to try and sync up and take a look at where
> we stand w/ the cachemap portion of the code. I think there where
> still issues with gathering/passing in the correct attributes.
>
> Thanks,
> Terence

Presumably, the aliasing will only bite where eg the X server sets up
MTRRs and PAT is used for the region also. For x86_64 and IA32, the
Intel IA32 system guides tell us that strong store ordering (ie
write-through) takes precendence over weaker store ordering (eg
write-combining), so we should be safe. For processors with known
errata with PAT etc, we can disable PAT support.

Would it be useful to get a rough patch covering point #1 onto LKML
for discussion?
___
Daniel J Blueman

Re: PAT status?

[Dave Jones]

On Thu, Dec 08, 2005 at 03:37:43PM +0000, Daniel J Blueman wrote:
 > Terence Ripperda wrote:
 > > Hi Jeff,
 > >
 > > I unfortunately haven't had much time to look at the status of the PAT
 > > code I had been working on. there are really 2 steps to the code:
 > >
 > > the first is enabling and configuring the PAT registers. this then
 > > allows a page table entry define that can be passed to traditional
 > > interfaces, such as remap_page_range or change_page_attr. this is
 > > pretty simple and we've been using a similar interface in our driver
 > > for some time now.
 > 
 > Presumably, the aliasing will only bite where eg the X server sets up
 > MTRRs and PAT is used for the region also. For x86_64 and IA32, the
 > Intel IA32 system guides tell us that strong store ordering (ie
 > write-through) takes precendence over weaker store ordering (eg
 > write-combining), so we should be safe. For processors with known
 > errata with PAT etc, we can disable PAT support.
 > 
 > Would it be useful to get a rough patch covering point #1 onto LKML
 > for discussion?

http://lwn.net/Articles/135883/ is Terrence's last patch
rediffed against 2.6.12 patch.

		Dave