Skip to contentSkip to conversation

AMD OSVW (OS Visible Workaround) for Xen

PATCH Applied Wei Huang 3 participants 6 messages Jul 1, 2010 – Jul 5, 2010

lore
Share & tools
lore

Wei Huang

author
#0 lore raw

PATCH 1/1 AMD OSVW (OS Visible Workaround) for Xen

This path enables AMD OSVW (OS Visible Workaround) feature for Xen. New AMD errata will have a OSVW id assigned in the future. OS is supposed to check OSVW status MSR to find out whether CPU has a specific erratum. Legacy errata are also supported in this patch: traditional family/model/stepping approach will be used if OSVW feature isn't applicable. This patch is adapted from Hans Rosenfeld's patch submitted to Linux kernel .

xen/arch/x86/cpu/amd.c +49 -1
diff -r aecf092da748 xen/arch/x86/cpu/amd.c
@@ -7,12 +7,12 @@
 #include <asm/io.h>
 #include <asm/msr.h>
 #include <asm/processor.h>
+#include <asm/amd.h>
 #include <asm/hvm/support.h>
 #include <asm/setup.h> /* amd_init_cpu */
 #include <asm/acpi.h>
 
 #include "cpu.h"
-#include "amd.h"
 
 /*
  * Pre-canned values for overriding the CPUID features 
@@ -145,6 +145,54 @@
 		wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
 		wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
 	}
+}
+
+/*
+ * Check for the presence of an AMD erratum. Arguments are defined in amd.h 
+ * for each known erratum. Return 1 if erratum is found.
+ */
+int cpu_has_amd_erratum(const struct cpuinfo_x86 *cpu, int osvw, ...) 
+{
+	va_list ap;
+	u32 range;
+	u32 ms;
+	
+	if (cpu->x86_vendor != X86_VENDOR_AMD)
+		return 0;
+
+	va_start(ap, osvw);
+
+	if (osvw) {
+		u16 osvw_id = va_arg(ap, int);
+
+		if (cpu_has(cpu, X86_FEATURE_OSVW)) {
+			u64 osvw_len;
+			rdmsrl(MSR_AMD_OSVW_ID_LENGTH, osvw_len);
+
+			if (osvw_id < osvw_len) {
+				u64 osvw_bits;
+				rdmsrl(MSR_AMD_OSVW_STATUS + (osvw_id >> 6), 
+				       osvw_bits);
+
+				va_end(ap);
+				return (osvw_bits >> (osvw_id & 0x3f)) & 0x01;
+			}
+		}
+	}
+
+	/* OSVW unavailable or ID unknown, match family-model-stepping range */
+	ms = (cpu->x86_model << 8) | cpu->x86_mask;
+	while ((range = va_arg(ap, int))) {
+		if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) &&
+		    (ms >= AMD_MODEL_RANGE_START(range)) &&
+		    (ms <= AMD_MODEL_RANGE_END(range))) {
+			va_end(ap);
+			return 1;
+		}
+	}
+
+	va_end(ap);
+	return 0;
 }
 
 /*
xen/arch/x86/cpu/amd.h deleted +0 -103

103 lines not on this page · raw message

xen/arch/x86/hvm/svm/asid.c +2 -2
diff -r aecf092da748 xen/arch/x86/hvm/svm/asid.c
@@ -21,14 +21,14 @@
 #include <xen/lib.h>
 #include <xen/perfc.h>
 #include <asm/hvm/svm/asid.h>
+#include <asm/amd.h>
 
 void svm_asid_init(struct cpuinfo_x86 *c)
 {
     int nasids = 0;
 
     /* Check for erratum #170, and leave ASIDs disabled if it's present. */
-    if ( (c->x86 == 0x10) ||
-         ((c->x86 == 0xf) && (c->x86_model >= 0x68) && (c->x86_mask >= 1)) )
+    if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) )
         nasids = cpuid_ebx(0x8000000A);
 
     hvm_asid_init(nasids);
xen/arch/x86/hvm/svm/svm.c +3 -2
diff -r aecf092da748 xen/arch/x86/hvm/svm/svm.c
@@ -34,6 +34,7 @@
 #include <asm/regs.h>
 #include <asm/cpufeature.h>
 #include <asm/processor.h>
+#include <asm/amd.h>
 #include <asm/types.h>
 #include <asm/debugreg.h>
 #include <asm/msr.h>
@@ -846,8 +847,8 @@
 {
     uint64_t msr_content;
 
-    /* only family 10h is affected */
-    if ( c->x86 != 0x10 )
+    /* check whether CPU is affected */
+    if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_383) )
         return;
 
     /* use safe methods to be compatible with nested virtualization */
xen/include/asm-x86/amd.h new file +138 -0

138 lines not on this page · raw message

xen/include/asm-x86/msr-index.h +4 -0
diff -r aecf092da748 xen/include/asm-x86/msr-index.h
@@ -252,6 +252,10 @@
 #define MSR_AMD_PATCHLEVEL		0x0000008b
 #define MSR_AMD_PATCHLOADER		0xc0010020
 
+/* AMD OS Visible Workaround MSRs */
+#define MSR_AMD_OSVW_ID_LENGTH          0xc0010140
+#define MSR_AMD_OSVW_STATUS             0xc0010141
+
 /* K6 MSRs */
 #define MSR_K6_EFER			0xc0000080
 #define MSR_K6_STAR			0xc0000081

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Applied
#1 lore raw
Quoted 7 lines · Wei Huang

This path enables AMD OSVW (OS Visible Workaround) feature for Xen. New AMD errata will have a OSVW id assigned in the future. OS is supposed to check OSVW status MSR to find out whether CPU has a specific erratum. Legacy errata are also supported in this patch: traditional family/model/stepping approach will be used if OSVW feature isn't applicable. This patch is adapted from Hans Rosenfeld's patch submitted to Linux kernel .

Applied to xen-unstable. Is this for 4.0.1 also? It is a big patch and it doesn't say it actually fixes any issues...

-- Keir

Quoted 4 lines
author
#2 lore raw

Thanks very much. I don't think 4.0.1 needs this patch.

-Wei

Quoted 32 lines · Keir Fraser
Quoted 8 lines · Wei Huang

This path enables AMD OSVW (OS Visible Workaround) feature for Xen. New AMD errata will have a OSVW id assigned in the future. OS is supposed to check OSVW status MSR to find out whether CPU has a specific erratum. Legacy errata are also supported in this patch: traditional family/model/stepping approach will be used if OSVW feature isn't applicable. This patch is adapted from Hans Rosenfeld's patch submitted to Linux kernel .

Applied to xen-unstable. Is this for 4.0.1 also? It is a big patch and it doesn't say it actually fixes any issues...

-- Keir

Quoted 5 lines

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#3 lore raw
Quoted 2 lines
Quoted 1 line
Quoted 1 line · Wei Huang

Thanks very much. I don't think 4.0.1 needs this patch.

I was about to reply with the opposite statement - why do you think so?

Quoted 13 lines
Quoted 12 lines · Keir Fraser
Quoted 8 lines · Wei Huang

This path enables AMD OSVW (OS Visible Workaround) feature for Xen. New AMD errata will have a OSVW id assigned in the future. OS is supposed to check OSVW status MSR to find out whether CPU has a specific erratum. Legacy errata are also supported in this patch: traditional family/model/stepping approach will be used if OSVW feature isn't applicable. This patch is adapted from Hans Rosenfeld's patch submitted to Linux kernel .

Quoted 2 lines
Quoted 2 lines

Applied to xen-unstable. Is this for 4.0.1 also? It is a big patch and it doesn't say it actually fixes any issues...

It's big only because of it moving around amd.h...

The issue it fixes is that newer AMD processor families apparently also require the workaround for erratum 383 (previously applied to Fam10 only).

Jan

#4 lore raw

Hi Jan,

My thought was that this patch won't affect newer families of CPUs (i.e. production parts). I expected this erratum will be fixed on them. But if you disagree, I will ask Keir to apply it to Xen 4.0.1.

Thanks,
-Wei
________________________________________
From: Jan Beulich [[email protected]]
Sent: Monday, July 05, 2010 2:11 AM
To: Huang2, Wei; Keir Fraser
Cc: Rosenfeld, Hans; [email protected]
Subject: Re: [Xen-devel] Re: [PATCH] AMD OSVW (OS Visible Workaround) for Xen

Quoted 2 lines
Quoted 1 line
Quoted 1 line · Wei Huang

Thanks very much. I don't think 4.0.1 needs this patch.

I was about to reply with the opposite statement - why do you think so?

Quoted 13 lines
Quoted 12 lines · Keir Fraser
Quoted 8 lines · Wei Huang

This path enables AMD OSVW (OS Visible Workaround) feature for Xen. New AMD errata will have a OSVW id assigned in the future. OS is supposed to check OSVW status MSR to find out whether CPU has a specific erratum. Legacy errata are also supported in this patch: traditional family/model/stepping approach will be used if OSVW feature isn't applicable. This patch is adapted from Hans Rosenfeld's patch submitted to Linux kernel .

Quoted 2 lines
Quoted 2 lines

Applied to xen-unstable. Is this for 4.0.1 also? It is a big patch and it doesn't say it actually fixes any issues...

It's big only because of it moving around amd.h...

The issue it fixes is that newer AMD processor families apparently also require the workaround for erratum 383 (previously applied to Fam10 only).

Jan

#5 lore raw
Quoted 3 lines
Quoted 1 line
Quoted 1 line · Wei

My thought was that this patch won't affect newer families of CPUs (i.e. production parts). I expected this erratum will be fixed on them. But if you

If you know that's going to be the case, then I agree.

Quoted 1 line

disagree, I will ask Keir to apply it to Xen 4.0.1.

Jan