All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Raj, Ashok" <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
	Borislav Petkov <bp@suse.de>, Tony Luck <tony.luck@intel.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: Re: [Patch V1 2/3] x86, mce: Add infrastructure required to support LMCE
Date: Mon, 1 Jun 2015 11:48:57 -0700	[thread overview]
Message-ID: <20150601184857.GA9646@linux.intel.com> (raw)
In-Reply-To: <20150529174439.GO31435@pd.tnic>

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



  parent reply	other threads:[~2015-06-01 19:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29 16:27 [Patch V1 0/3] x86 Local Machine Check Exception (LMCE) Ashok Raj
2015-05-29 16:28 ` [Patch V1 1/3] x86, mce: Add LMCE definitions Ashok Raj
2015-05-29 16:28 ` [Patch V1 2/3] x86, mce: Add infrastructure required to support LMCE Ashok Raj
2015-05-29 17:35   ` Borislav Petkov
2015-05-29 17:44   ` Borislav Petkov
2015-06-01 17:09     ` Raj, Ashok
2015-06-01 18:48     ` Raj, Ashok [this message]
2015-06-01 19:37       ` Borislav Petkov
2015-05-29 16:28 ` [Patch V1 3/3] x86, mce: Handling LMCE events Ashok Raj
2015-05-29 17:36   ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150601184857.GA9646@linux.intel.com \
    --to=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.