mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Jones <davej@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH] i386, x86_64 Initial PAT implementation
Date: Tue, 30 Aug 2005 19:39:43 -0600	[thread overview]
Message-ID: <m1mzmyq3z4.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20050830170600.GA10042@redhat.com> (Dave Jones's message of "Tue, 30 Aug 2005 13:06:00 -0400")

Dave Jones <davej@redhat.com> 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 hard
>  > > to abuse, and should raise no additional aliasing problems.  No
>  > > attempt has been made to fix theoretical aliasing problems.
>  > 
>  > Even an uncached/cached alias causes random memory corruption or an MCE
>  > on x86 systems. In fact it can occur even for an alias not in theory
>  > touched by the CPU if it happens to prefetch into or speculate the
>  > address.
>  > 
>  > Also be sure to read the PII Xeon errata - early PAT has a bug or two.
>
> There are various PAT errata all the way through to Pentium-M iirc.

Thanks, I have just read through all of them and none of them look
like a problem.

The primary issue is that you can't count on being able to use
the upper 4 PAT entries.

The most painful is that on the Pentium-III and I believe on the Pentium-M
there are occasions where PAT will fail to promote an UC entry from
the mtrrs to WC.  The page will remain UC resulting in louzy performance.

It looks like you can hard hang a Pentium-4 by mixing uncached and
writeback memory attributes.

Eric


      reply	other threads:[~2005-08-31  1:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30  0:20 Eric W. Biederman
     [not found] ` <200508300230.39844.ak@suse.de>
2005-08-30  1:49   ` Eric W. Biederman
     [not found]     ` <200508300412.55027.ak@suse.de>
2005-08-30  6:21       ` solving page table access attribute aliasing Eric W. Biederman
     [not found]         ` <200508301714.35017.ak@suse.de>
2005-08-30 15:50           ` Eric W. Biederman
2005-08-30 14:45 ` [PATCH] i386, x86_64 Initial PAT implementation Alan Cox
2005-08-30 14:50   ` Andi Kleen
2005-08-30 15:31     ` Mikael Pettersson
2005-08-30 16:01       ` Eric W. Biederman
2005-08-30 15:20   ` Eric W. Biederman
     [not found]     ` <200508301748.50941.ak@suse.de>
2005-08-30 16:06       ` Eric W. Biederman
2005-08-30 17:06   ` Dave Jones
2005-08-31  1:39     ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1mzmyq3z4.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®