On 16.12.2025 11:08, Teddy Astie wrote:
> Le 16/12/2025 à 10:03, Jan Beulich a écrit :
>> @@ -1130,6 +1152,28 @@ static void cf_check init_amd(struct cpu
>> !cpu_has(c, X86_FEATURE_BTC_NO))
>> setup_force_cpu_cap(X86_FEATURE_BTC_NO);
>> break;
>> +
>> + case 0x1a:
>> + /*
>> + * Zen5 have an error that causes the 16- and 32-bit forms of
>> + * RDSEED to frequently return 0 while signaling success (CF=1).
>> + * Sadly at the time of writing the fixed microcode revision is
>> + * known for only two of the models.
>
> Is it still two models ?
Oops - s/two/some/. Thanks for noticing.
>> + */
>> + if (c == &boot_cpu_data &&
>> + cpu_has(c, X86_FEATURE_RDSEED) &&
>> + !is_forced_cpu_cap(X86_FEATURE_RDSEED)) {
>> + static const char __initconst text[] =
>> + "RDSEED32 is unreliable on this hardware;
>> disabling its exposure\n";
>> +
>> + if (zen5_rdseed_good(c))
>> + break;
>> +
>> + setup_clear_cpu_cap(X86_FEATURE_RDSEED);
>> + cpuidmask_defaults._7ab0 &=
>> ~cpufeat_mask(X86_FEATURE_RDSEED);
>> + warning_add(text);
>> + }
>> + break;
>
> Do we still want to disable if we are running in a hypervisor; we can
> expect the host to emulate the instructions to workaround the issue ?
That would only work if we knew the host intercepts that insn. We don't
ourselves, so I can't see us legitimately expecting anyone else to do so. Plus
while I'm aware RDSEED can be intercepted on VMX, I'm unaware of there being
equivalent functionality on SVM (PM vol 3 does not yield any hit when searching
for RDSEED).
Jan
