[PATCH 2/3] x86/amd: Exclude K8 RevD and earlier from levelling

Andrew Cooper posted 3 patches 1 week, 3 days ago
[PATCH 2/3] x86/amd: Exclude K8 RevD and earlier from levelling
Posted by Andrew Cooper 1 week, 3 days ago
Between RevD and RevE silicon, the feature MSRs moved location.  This property
is highlighted by the suggested workaround for Erratum #110 which gives the
two different MSRs for the extended feature leaf.

The other feature MSRs are not given and while they're easy enough to figure
out I don't have any K8's to test the result with.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/amd.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 4dc9157836ad..73f43b0f9174 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -117,10 +117,12 @@ static void __init noinline probe_masking_msrs(void)
 	/*
 	 * First, work out which masking MSRs we should have, based on
 	 * revision and cpuid.
+	 *
+	 * Fam11h doesn't support masking at all.  FamFh RevD and earlier had
+	 * the feature MSRs in different locations, as can be seen by the
+	 * suggested workaround for Erratum #110, docID 25759.
 	 */
-
-	/* Fam11 doesn't support masking at all. */
-	if (c->x86 == 0x11)
+	if (c->family == 0x11 || (c->family == 0xf && c->model < 0x20))
 		return;
 
 	cpuidmask_defaults._1cd =
-- 
2.39.5


Re: [PATCH 2/3] x86/amd: Exclude K8 RevD and earlier from levelling
Posted by Jan Beulich 4 days, 10 hours ago
On 02.12.2025 11:57, Andrew Cooper wrote:
> Between RevD and RevE silicon, the feature MSRs moved location.  This property
> is highlighted by the suggested workaround for Erratum #110 which gives the
> two different MSRs for the extended feature leaf.
> 
> The other feature MSRs are not given and while they're easy enough to figure
> out I don't have any K8's to test the result with.

I can see where you're coming from, but shouldn't we then first document those
extremely old models as unsupported in SUPPORT.md?

Jan