Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Eric W. Biederman
Dave Jones <[EMAIL PROTECTED]> writes: > On Tue, Aug 30, 2005 at 03:45:36PM +0100, Alan Cox wrote: > > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > > > ways. Currently this code only allows for an additional flavor > > > of uncached access to physical memory addresses which sh

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Dave Jones
On Tue, Aug 30, 2005 at 03:45:36PM +0100, Alan Cox wrote: > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > > ways. Currently this code only allows for an additional flavor > > of uncached access to physical memory addresses which should be hard > > to abuse, and should raise no

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Eric W. Biederman
Andi Kleen <[EMAIL PROTECTED]> writes: > On Tuesday 30 August 2005 17:20, Eric W. Biederman wrote: > >> Right. To the best of my understanding problem aliases are either >> uncached/write-back or write-combine/write-back. I don't think >> uncached/write-combine can cause problems. My basic reas

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Eric W. Biederman
Mikael Pettersson <[EMAIL PROTECTED]> writes: > Andi Kleen writes: > > On Tuesday 30 August 2005 16:45, Alan Cox wrote: > > > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > > > > ways. Currently this code only allows for an additional flavor > > > > of uncached access to physic

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Mikael Pettersson
Andi Kleen writes: > On Tuesday 30 August 2005 16:45, Alan Cox wrote: > > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > > > ways. Currently this code only allows for an additional flavor > > > of uncached access to physical memory addresses which should be hard > > > to abuse,

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Eric W. Biederman
Alan Cox <[EMAIL PROTECTED]> writes: > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: >> ways. Currently this code only allows for an additional flavor >> of uncached access to physical memory addresses which should be hard >> to abuse, and should raise no additional aliasing problem

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Andi Kleen
On Tuesday 30 August 2005 16:45, Alan Cox wrote: > On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > > ways. Currently this code only allows for an additional flavor > > of uncached access to physical memory addresses which should be hard > > to abuse, and should raise no additional al

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-30 Thread Alan Cox
On Llu, 2005-08-29 at 18:20 -0600, Eric W. Biederman wrote: > ways. Currently this code only allows for an additional flavor > of uncached access to physical memory addresses which should be hard > to abuse, and should raise no additional aliasing problems. No > attempt has been made to fix theor

Re: [PATCH] i386, x86_64 Initial PAT implementation

2005-08-29 Thread Eric W. Biederman
Andi Kleen <[EMAIL PROTECTED]> writes: > On Tuesday 30 August 2005 02:20, Eric W. Biederman wrote: >> PAT (or setting caching policy in the page table entries) has been a >> long desired feature in the kernel and as large memory sizes become >> more prevalent it becomes increasingly hard to specif

[PATCH] i386, x86_64 Initial PAT implementation

2005-08-29 Thread Eric W. Biederman
PAT (or setting caching policy in the page table entries) has been a long desired feature in the kernel and as large memory sizes become more prevalent it becomes increasingly hard to specify all of the regions that need write-back caching with just 8 MTRRs much less add in the write-combining reg