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

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.

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()?

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.

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()?

It has nothing to do with cpuid.

blast@blast-devserv ~> sudo cpucontrol -m 0xc0011002 /dev/cpuctl1
MSR 0xc0011002: 0x00000001 0xf1bf97ab
blast@blast-devserv ~> sudo cpucontrol -i 1 /dev/cpuctl1
cpuid level 0x1: 0x00b40f40 0x01200800 0x7ed8320b 0x178bfbff
blast@blast-devserv ~> sudo cpucontrol -i 7 /dev/cpuctl1
cpuid level 0x7: 0x00000001 0xf1bf97ab 0x19405fde 0x10000110
blast@blast-devserv ~> sudo cpucontrol -m 0xc0011002&=~0x40000 /dev/cpuctl1
blast@blast-devserv ~> sudo cpucontrol -m 0xc0011002 /dev/cpuctl1
MSR 0xc0011002: 0x00000001 0xf1bb97ab
blast@blast-devserv ~> sudo cpucontrol -i 1 /dev/cpuctl1
cpuid level 0x1: 0x00b40f40 0x01200800 0x7ed8320b 0x178bfbff
blast@blast-devserv ~> sudo cpucontrol -i 7 /dev/cpuctl1
cpuid level 0x7: 0x00000001 0xf1bb97ab 0x19405fde 0x10000110