Loading into the wrong variable here.

Maybe call it "RDSEED SRBDS mitigation"?

Is this the proposed default? I was under the impression that the kernel PRNG mixes several entropy sources, including that of RDRAND, and the Intel doc suggests that the mitigation is not necessary in that case.

Why does it need to be an external parameter? Can't we just use smp_started to determine whether to signal remote CPUs?

So mitigations.rngds.enable=0 means that the mitigation is enabled? That seems confusing. Shouldn't the sense be reversed?

Extra newline.

Answering both this and a proposal to call it "RDSEED SRBDS mitigation". We are probably somewhat fine in kernel, but usermode can use RDSEED/RDRAND, and same for any OS that is run inside VMM. So the Intel' decision to have the mitigation enabled by default makes sense.

The knob actually controls the optimization of access to MCU, which explains why it is called 'enable'. It enables faster RDSEED (I saw numbers like 3% of the previous performance in microbenchmark after new microcode is loaded).

May be, but there are more _recalculate() around, and this instance is consistent with other code. If changing, I will consider doing single pass over all of it.

It means that the optimization is enabled.

Ok.

According to the doc, the mitigation can be disabled in some cases if TSX is disabled.

But the sysctl name contains "mitigation", so it sounds like "enable" applies to the mitigation, not the optimization. As I understand, the optimization is simply "disable the mitigation".

And MDS_NO. I did not wanted to do that, and still do not want. We slowly make the mitigation sysctls into the spreadsheet with formulas. I want to keep it simpler, user can decide himself.

Ok, I reverted this.