svm_msr: Allow reading and writing MSR_AMD_CPUID01 and 07.

[aokblast]

Summary

Zen5 CPUs have a bug on RDSEED that cause CPU mulfunction. In this case,
Linux disable such behavior by clearing specific MSR bit. To allow
Kernel clear the flag correctly without panic, we enable read/write to
these two related MSR.

[markj]

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

[aokblast]

In D56312#1289170, @markj wrote:

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

The MSR involved isn’t publicly documented; it’s only used to disable RDSEED across the Linux kernel (see the reference here: https://elixir.bootlin.com/linux/v6.19.11/source/arch/x86/kernel/cpu/amd.c#L1043
).
The logic is straightforward: it reads the MSR, checks whether the relevant bit is enabled, and clears it if so. If the bit isn’t set, it does nothing.
I haven’t been able to test this yet since it requires a Linux 6.19+ kernel. I’m still waiting for feedback from the reporter.

[markj]

In D56312#1289914, @aokblast wrote:

In D56312#1289170, @markj wrote:

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

The MSR involved isn’t publicly documented; it’s only used to disable RDSEED across the Linux kernel (see the reference here: https://elixir.bootlin.com/linux/v6.19.11/source/arch/x86/kernel/cpu/amd.c#L1043
).
The logic is straightforward: it reads the MSR, checks whether the relevant bit is enabled, and clears it if so. If the bit isn’t set, it does nothing.
I haven’t been able to test this yet since it requires a Linux 6.19+ kernel. I’m still waiting for feedback from the reporter.

Then, don't we want to honour the MSR by ensuring that CPUID_STDEXT_RDSEED is not returned in x86_emulate_cpuid()?

[aokblast]

In D56312#1290228, @markj wrote:

In D56312#1289914, @aokblast wrote:

In D56312#1289170, @markj wrote:

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

The MSR involved isn’t publicly documented; it’s only used to disable RDSEED across the Linux kernel (see the reference here: https://elixir.bootlin.com/linux/v6.19.11/source/arch/x86/kernel/cpu/amd.c#L1043
).
The logic is straightforward: it reads the MSR, checks whether the relevant bit is enabled, and clears it if so. If the bit isn’t set, it does nothing.
I haven’t been able to test this yet since it requires a Linux 6.19+ kernel. I’m still waiting for feedback from the reporter.

Then, don't we want to honour the MSR by ensuring that CPUID_STDEXT_RDSEED is not returned in x86_emulate_cpuid()?

That is a good point, I don't know the exact behavior of this MSR. I will try to reach AMD guy to do so. As far as I know, cpuid is read only from both hardware and software after bootup, so I am not sure if it affects cpuid.