xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Huang <wei.huang2@amd.com>
To: Keir Fraser <keir@xen.org>
Cc: "'xen-devel@lists.xensource.com'" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] MTRR: clear DramModEn bit of sys_cfg MSR
Date: Tue, 5 Apr 2011 12:26:42 -0500	[thread overview]
Message-ID: <4D9B50D2.8040900@amd.com> (raw)
In-Reply-To: <C9C0C0D4.2C500%keir@xen.org>

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Sorry for the indention issue... I agree that it is better to move 
check-and_fixup code to init_amd() function. See the new patch.

My understanding is that RdMem and WrMem are never going to become 1: 
BIOS are supposed to set sys_cfg[DramModEn] bit to 0 before OS takes 
over. As a result, RdMem and WrMem are read as 0 in fixed MTRRs. Unless 
Xen turn these bits to 1 (which I don't see from the code), 
k8_enable_fixed_iorrs() is useless. My 2nd patch removes 
k8_enable_fixed_iorrs(). If you have concern, we don't have to apply 
this patch. But I don't think we shouldn't move it to amd.c. 
k8_enable_fixed_iorrs() is unrelated in that file.

Thanks,
-Wei

On 04/05/2011 06:51 AM, Keir Fraser wrote:
> On 04/04/2011 23:23, "Wei Huang"<wei.huang2@amd.com>  wrote:
>
>> Some buggy BIOS might set sys_cfg DramModEn bit to 1, which can cause
>> unexpected behavior on AMD platforms. This patch clears DramModEn bit.
>> The patch was derived from upstream kernel patch (see
>> https://patchwork.kernel.org/patch/11425/).
> This patch also removes k8_enable_fixed_iorrs(), and it's not clear why.
> That would at least belong in a separate patch, but I would think we don't
> want to delete that code anyway.
>
> The indentation is wrong (spaces in a file that is hard-tab-indented). And
> the printk is probably unnecessary -- at most you should print it once
> rather than potentially for every core brought up.
>
> But further, I don't see why you need to hang off {get,set}_fixed_ranges at
> all. Why not do this check-and-fixup in cpu/amd.c:init_amd()? It's a handy
> early-cpu-bringup amd-specific function which is rather designed ofr this
> kind of purpose. The k8_enable_fixed_iorrs() work could better be done in
> the same place, too (perhaps move it in a separate patch?).
>
>   -- Keir
>
>> Signed-off-by: Wei Huang<wei.huang2@amd.com>
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>


[-- Attachment #2: amd_fix_syscfg.txt --]
[-- Type: text/plain, Size: 1624 bytes --]

# HG changeset patch
# User Wei Huang <wei.huang2@amd.com>
# Date 1302023015 18000
# Node ID 4a9430efe643d18c8b69d377a6e70325ac7a9483
# Parent  8957b6b3f43932b4e50f489bc50ed87ab1a286cd
MTRR: correct DramModEn bit of SYS_CFG MSR

Some buggy BIOS might set SYS_CFG DramModEn bit to 1, which can cause unexpected behavior on AMD platforms. This patch clears DramModEn bit if it is 1.

Signed-off-by: Wei Huang <wei.huang2@amd.com>

diff -r 8957b6b3f439 -r 4a9430efe643 xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c	Tue Apr 05 11:13:02 2011 -0500
+++ b/xen/arch/x86/cpu/amd.c	Tue Apr 05 12:03:35 2011 -0500
@@ -300,6 +300,32 @@
 		on_each_cpu(disable_c1e, NULL, 1);
 }
 
+/*
+ * BIOS is expected to clear MtrrFixDramModEn bit. According to AMD BKDG : 
+ * "The MtrrFixDramModEn bit should be set to 1 during BIOS initalization of 
+ * the fixed MTRRs, then cleared to 0 for operation."
+ */
+static void check_syscfg_dram_mod_en(void)
+{
+	uint64_t syscfg;
+	static int printed = 0;
+
+	if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+		(boot_cpu_data.x86 >= 0x0f)))
+		return;
+
+	rdmsrl(MSR_K8_SYSCFG, syscfg);
+	if (syscfg & K8_MTRRFIXRANGE_DRAM_MODIFY) {
+		if (!printed) {
+			printed++;
+			printk(KERN_ERR "MTRR: SYSCFG[MtrrFixDramModEn] not "
+				"cleared by BIOS, clearing this bit\n");
+		}
+		syscfg &= ~K8_MTRRFIXRANGE_DRAM_MODIFY;
+		wrmsrl(MSR_K8_SYSCFG, syscfg);
+	}
+}
+
 static void __devinit init_amd(struct cpuinfo_x86 *c)
 {
 	u32 l, h;
@@ -453,6 +479,8 @@
 		disable_c1_ramping();
 
 	set_cpuidmask(c);
+
+	check_syscfg_dram_mod_en();
 }
 
 static struct cpu_dev amd_cpu_dev __cpuinitdata = {

[-- Attachment #3: amd_remove_k8_enable_fixed_iorrs.txt --]
[-- Type: text/plain, Size: 1873 bytes --]

# HG changeset patch
# User Wei Huang <wei.huang2@amd.com>
# Date 1302023857 18000
# Node ID effc147d35ce692c5d55d007a722869c372963c1
# Parent  4a9430efe643d18c8b69d377a6e70325ac7a9483
MTRR: remove k8_enable_fixed_iorrs()

AMD64 defines two special bits (bit 3 and 4) RdMem and WrMem in fixed MTRR type. Their values are supposed to be 0 after BIOS hands the control to OS according to AMD BKDG. Unless OS specificially turn them on, they are kept 0 all the time. As a result, k8_enable_fixed_iorrs() is unnecessary and removed from upstream kernel (see https://patchwork.kernel.org/patch/11425/). This patch does the same thing.

Signed-off-by: Wei Huang <wei.huang2@amd.com>

diff -r 4a9430efe643 -r effc147d35ce xen/arch/x86/cpu/mtrr/generic.c
--- a/xen/arch/x86/cpu/mtrr/generic.c	Tue Apr 05 12:03:35 2011 -0500
+++ b/xen/arch/x86/cpu/mtrr/generic.c	Tue Apr 05 12:17:37 2011 -0500
@@ -116,20 +116,6 @@
 }
 
 /**
- * Enable and allow read/write of extended fixed-range MTRR bits on K8 CPUs
- * see AMD publication no. 24593, chapter 3.2.1 for more information
- */
-static inline void k8_enable_fixed_iorrs(void)
-{
-	uint64_t msr_content;
-
-	rdmsrl(MSR_K8_SYSCFG, msr_content);
-	mtrr_wrmsr(MSR_K8_SYSCFG, msr_content 
-				| K8_MTRRFIXRANGE_DRAM_ENABLE
-				| K8_MTRRFIXRANGE_DRAM_MODIFY);
-}
-
-/**
  * Checks and updates an fixed-range MTRR if it differs from the value it
  * should have. If K8 extenstions are wanted, update the K8 SYSCFG MSR also.
  * see AMD publication no. 24593, chapter 7.8.1, page 233 for more information
@@ -145,10 +131,6 @@
 	val = ((uint64_t)msrwords[1] << 32) | msrwords[0];
 
 	if (msr_content != val) {
-		if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
-		    boot_cpu_data.x86 == 15 &&
-		    ((msrwords[0] | msrwords[1]) & K8_MTRR_RDMEM_WRMEM_MASK))
-			k8_enable_fixed_iorrs();
 		mtrr_wrmsr(msr, val);
 		*changed = TRUE;
 	}

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  reply	other threads:[~2011-04-05 17:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-04 22:23 [PATCH] MTRR: clear DramModEn bit of sys_cfg MSR Wei Huang
2011-04-05 11:51 ` Keir Fraser
2011-04-05 17:26   ` Wei Huang [this message]
2011-04-05 18:12     ` Keir Fraser

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=4D9B50D2.8040900@amd.com \
    --to=wei.huang2@amd.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /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;
as well as URLs for NNTP newsgroup(s).