Messages in this thread | | | Date | Mon, 1 Jun 2015 11:48:57 -0700 | From | "Raj, Ashok" <> | Subject | Re: [Patch V1 2/3] x86, mce: Add infrastructure required to support LMCE |
| |
Hi Boris
If you got a blank email, sorry about that. Its been a while since i used mutt and my setup was goofed up probably. Or i might have read your signature a bit too literally :-)
> > + > > + if (mca_cfg.lmce_disabled) > > + return false; > > + > > + rdmsrl(MSR_IA32_MCG_CAP, cap); > > + rdmsrl(MSR_IA32_FEATURE_CONTROL, feature_ctl); >
> One more thing: You should check MCG_LMCE_P *first* and only read > MSR_IA32_FEATURE_CONTROL if MCG_LMCE_P is set - otherwise this'll start > blowing up on older machines which don't sport that new MSR and on kvm.
I did re-organize this to read better in my upcoming post. But in general reading FEATURE_CONTROL isn't bad. It wont trip on a #GP for e.g. FEATURE_CONTROL has been around for a while. Only when we set reserved bits without checking would be bad. > > > + lmce_bios_support = ((feature_ctl & (FEATURE_CONTROL_LMCE_BITS)) == > > + (FEATURE_CONTROL_LMCE_BITS)); > > + > Also, why do we need to look at MCG_SER_P for LMCE?
Good point. Its required by architecture, since it depends on recovery support in processors to work. I forgot to add that to the SDM when i made those updates. I will update the SDM appropriately on my next attempt at it.
> > Btw, we do that already in __mcheck_cpu_cap_init() so you could check > mca_cfg.ser here instead.
Could have used mca_cfg. But just being paranoid, would be safe to test per-cpu instead of taking the global based on BSP. Just in case someone put a system with slightly different capabilities.
> > > ECO tip #101: Trim your mails when you reply.
Sorry about my config challenges.. hopefully this makes it out with all the responses :-)
Cheers, Ashok
| |