>> And I call this from mcheck_init().
>> I tested the above bits on AMD and the severities grading works fine.
>>
>> Should we also come up with a '_default' function to assign to mce_severity
>> function pointer?
>
>I think that should be
>
> default:
> WARN_ONCE("WTF?!");
>
On Fri, Mar 20, 2015 at 10:59:33AM -0500, Aravind Gopalakrishnan wrote:
> Ok, Here's how I have it currently:
> void __init mcheck_vendor_init_severity(void)
> {
> struct cpuinfo_x86 *c = &boot_cpu_data;
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
>
On 3/19/2015 12:15 PM, Luck, Tony wrote:
It would be best if what Tony suggested comes ontop of your patch with
his Suggested-by: tag. This ordering should be also the easiest wrt
functionality and bisectability.
Ok, I'll have it ready and send out a V2 by tomorrow if there are no
other commen
>> It would be best if what Tony suggested comes ontop of your patch with
>> his Suggested-by: tag. This ordering should be also the easiest wrt
>> functionality and bisectability.
>>
>>
>
> Ok, I'll have it ready and send out a V2 by tomorrow if there are no
> other comments/reviews.
Fame & glor
On 3/19/2015 10:53 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 09:41:01AM -0500, Aravind Gopalakrishnan wrote:
Ok, I'll work on this and prepend the changes to the current version
of the patch. Would you prefer the changes be in a separate patch or
lump it in along with current version?
On Thu, Mar 19, 2015 at 09:41:01AM -0500, Aravind Gopalakrishnan wrote:
> Ok, I'll work on this and prepend the changes to the current version
> of the patch. Would you prefer the changes be in a separate patch or
> lump it in along with current version?
It would be best if what Tony suggested com
On 3/19/2015 4:29 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 12:01:32AM +, Luck, Tony wrote:
One other thought. Instead of the run-time test to see if this is an AMD
processor on every call
to this function, would it be cleaner to:
1) Rename existing mce_severity() function to mce
On Thu, Mar 19, 2015 at 12:01:32AM +, Luck, Tony wrote:
> One other thought. Instead of the run-time test to see if this is an AMD
> processor on every call
> to this function, would it be cleaner to:
>
> 1) Rename existing mce_severity() function to mce_severity_intel()
> 2) Declare a funct
One other thought. Instead of the run-time test to see if this is an AMD
processor on every call
to this function, would it be cleaner to:
1) Rename existing mce_severity() function to mce_severity_intel()
2) Declare a function pointer named mce_severity.
3) Assign that pointer to the _intel() o
On Tue, Mar 17, 2015 at 01:41:46PM -0500, Aravind Gopalakrishnan wrote:
> return MCE_AR_SEVERITY if ctx == IN_USER also needs to be within this
> block here. Will do that and resend.
Right, but please wait a couple of days for people to take a look first.
Thanks.
--
Regards/Gruss,
Boris.
E
On 3/17/2015 5:20 AM, Borislav Petkov wrote:
On Mon, Mar 16, 2015 at 12:16:04PM -0500, Aravind Gopalakrishnan wrote:
+/* keeping amd_mce_severity in sync with AMD error scope heirarchy table */
+static int amd_mce_severity(struct mce *m, enum context ctx)
+{
+ /* Processor Context Corrupt,
On Mon, Mar 16, 2015 at 12:16:04PM -0500, Aravind Gopalakrishnan wrote:
> +/* keeping amd_mce_severity in sync with AMD error scope heirarchy table */
> +static int amd_mce_severity(struct mce *m, enum context ctx)
> +{
> + /* Processor Context Corrupt, no need to fumble too much, die! */
> +
* Borislav Petkov wrote:
> On Tue, Mar 17, 2015 at 08:42:14AM +0100, Ingo Molnar wrote:
> > So it would be nice to see actual use of this new facility, within the
> > same patch series?
>
> All AMD hardware will use this. It is basically a much cleaner,
> nicer and *actually* *readable* severi
On Tue, Mar 17, 2015 at 08:42:14AM +0100, Ingo Molnar wrote:
> So it would be nice to see actual use of this new facility, within the
> same patch series?
All AMD hardware will use this. It is basically a much cleaner, nicer
and *actually* *readable* severities grading function replacing the
defau
* Aravind Gopalakrishnan wrote:
> Add a severities function that caters to AMD processors.
> This allows us to do some vendor specific work within the
> function if necessary.
>
> Also, introduce a vendor flag bitfield which contains vendor
> specific flags. The severities code uses this to def
Add a severities function that caters to AMD processors.
This allows us to do some vendor specific work within the
function if necessary.
Also, introduce a vendor flag bitfield which contains vendor
specific flags. The severities code uses this to define error
scope based on the prescence of the f
16 matches
Mail list logo
