All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Cachemap for 2.6.12rc4-mm1.  Was Re: [PATCH] enhance x86 MTRR handling
Date: Fri, 13 May 2005 19:23:57 -0400	[thread overview]
Message-ID: <20050513232357.GB13846@redhat.com> (raw)
In-Reply-To: <42852CE2.4090102@zytor.com>

On Fri, May 13, 2005 at 03:40:34PM -0700, H. Peter Anvin wrote:
 > Dave Jones wrote:
 > 
 > >+	switch (boot_cpu_data.x86_vendor) {
 > >+	case X86_VENDOR_AMD:
 > >+		wrmsr(IA32_CR_PAT, AMD_PAT_31_0, AMD_PAT_63_32);
 > >+		atomic_inc(&pat_cpus_enabled);
 > >+		break;
 > >+	case X86_VENDOR_INTEL:
 > >+		wrmsr(IA32_CR_PAT, INTEL_PAT_31_0, INTEL_PAT_63_32);
 > >+		atomic_inc(&pat_cpus_enabled);
 > >+		break;
 > >+	default:
 > >+		printk("Unknown vendor in setup_pat()\n");
 > >+	}
 > 
 > Drop the vendor check; PAT is a generic x86 feature.  If AMD is not 
 > compatible (see below), then use X86_VENDOR_AMD: and default:.

Done. Does transmeta have PAT btw ? I know newer VIA has it,
but I haven't looked through the docs to double check its
implementation yet.

 > >+	/* checks copied from arch/i386/kernel/cpu/mtrr/main.c */
 > >+	/* do these only apply to mtrrs or pat as well? */
 > 
 > It would apply to both; the chipset wouldn't even know how it got invoked.

ACK, Comment dropped.

 > >+/* Here is the PAT's default layout on ia32 cpus when we are done.
 > >+ * PAT0: Write Back
 > >+ * PAT1: Write Combine
 > >+ * PAT2: Uncached
 > >+ * PAT3: Uncacheable
 > >+ * PAT4: Write Through
 > >+ * PAT5: Write Protect
 > >+ * PAT6: Uncached
 > >+ * PAT7: Uncacheable
 > 
 > Bad move.  Some (Intel) processors drop the top bit, so it's much better 
 > to pick the protection methods one cares about (usually WB, WC, UC) and 
 > stick them in the first four, then duplicate the whole thing in the 
 > second half.

Noted.

 > >+ * Note: On Athlon cpus PAT2/PAT3 & PAT6/PAT7 are both Uncacheable since 
 > >+ *	 there is no uncached type.
 > If one sets the PAT to "uncached", does one get the same function as 
 > "uncachable"?

AIUI, only as long as we don't have an MTRR covering the same range marked WC.
It seems to be the only thing I could find documenting the differences
between 'uncached' and 'uncacheable' in this context.
Though I've only looked through the Intel & AMD K8 docs, I don't have
the K7 ones to hand.

		Dave


  reply	other threads:[~2005-05-13 23:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-12  9:08 [PATCH] enhance x86 MTRR handling Jan Beulich
2005-05-12 16:18 ` Dave Jones
2005-05-12 17:02   ` David Addison
2005-05-12 21:41   ` [RFC] Cachemap for 2.6.12rc4-mm1. Was " Dave Jones
2005-05-13 13:29     ` Andi Kleen
2005-05-13 14:24       ` Dave Hansen
2005-05-13 14:35         ` Andi Kleen
2005-05-13 15:52       ` Dave Jones
2005-05-18 22:01         ` Terence Ripperda
2005-05-18 22:03           ` Andi Kleen
2005-05-18 22:15             ` Terence Ripperda
2005-05-18 22:42               ` Andi Kleen
2005-05-19  3:57             ` Randy Dunlap
2005-05-13 22:40     ` H. Peter Anvin
2005-05-13 23:23       ` Dave Jones [this message]
2005-05-13 23:36         ` H. Peter Anvin
2005-05-13 23:42           ` Dave Jones
2005-05-13 23:49             ` H. Peter Anvin

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=20050513232357.GB13846@redhat.com \
    --to=davej@redhat.com \
    --cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.