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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
