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
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
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
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
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
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
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
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
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 aliasing
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 problems. No
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, and should
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 physical memory
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 reason for
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
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 should be
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
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
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
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 specify all of
20 matches
Mail list logo
