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

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

On 08/12/2025 9:25 am, Jan Beulich wrote:
> 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?

Not especially, no.

There are Intel CPUs with no levelling capabilities at all, that have no
(non)support statement.  The levelling on most AMD CPUs is incomplete too.

PV Guest Kernels are required to use FEP to get the Xen-approved
version; it's only userspace which ends up adversely affected.

~Andrew

On 21.01.2026 12:52, Andrew Cooper wrote:
> On 08/12/2025 9:25 am, Jan Beulich wrote:
>> 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?
> 
> Not especially, no.
> 
> There are Intel CPUs with no levelling capabilities at all, that have no
> (non)support statement.  The levelling on most AMD CPUs is incomplete too.

Hmm, true.

Acked-by: Jan Beulich <jbeulich@suse.com>

Jan