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
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
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
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
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,
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
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
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
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
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
10 matches
Mail list logo