Messages in this thread | | | Subject | Re: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured | From | Jacob Keller <> | Date | Wed, 26 Feb 2020 12:41:09 -0800 |
| |
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. > > Thanks, > Jake >
Hi,
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.
Thanks, Jake
| |