On 2/25/2020 4:58 PM, Jacob Keller wrote:
On 2/25/2020 4:42 PM, Sean Christopherson wrote>> So there's something weird going on. Maybe "boot_cpu_has" in the
vmx_disabled_by_bios is wrong? Hmm.
Hmm, perhaps a bug somewhere else is overwriting the cpufeatures bit for X86_FEATURE_VMX. Let me see if I can reproduce from net-next.
If you have any further suggestions for debugging, I'm happy to help try to figure this out. To my eyes, it looks like somehow bits get reset... It's definitely not clear to me how this happens.
There is the get_cpu_caps call.. but that seems to correctly call apply_forced_caps at the end.
That's all I have time for today.
I kept digging into this, and I added a further print to the get_cpu_cap function.
It looks like get_cpu_cap is being called again *after* init_ia32_feat_ctl...
Digging further, I discovered this appears to be the call in setup_pku, which would only be enabled for systems which have X86_FEATURE_PKU enabled and supported. It's quite likely that test systems may not have had this feature, hence why it went undetected till now.
Because of the extra get_cpu_cap call, the capabilities are reset. Since we never use setup_clear_cpu_cap or pass NULL to clear_cpu_cap, the code that sets the global cpu_caps_cleared bits is not run.
It's not clear to me what the best fix for this is.
Perhaps init_ia32_feat_ctl should be something run during early_identify_cpu, since it's really checking global status (rdmsr), and not per-CPU status. And then it could directly operate to call setup_clear_cpu_cap, which would properly clear the bit globally, ensuring that apply_forced_caps kicks in?
Or this needs to somehow be run *after* setup_pku? But that doesn't feel very robust.