On Wed, Jan 18, 2017 at 09:34:13PM +0100, Borislav Petkov wrote:
> I'll run it tomorrow.
Ok, here it is, it looks ok while testing in a guest and injecting MCEs.
---
From: Borislav Petkov
Date: Wed, 18 Jan 2017 21:34:41 +0100
Subject: [PATCH] x86/MCE: Flip the TSC-adding logic
Add the TSC value
On Wed, Nov 09, 2016 at 07:06:04PM +0100, Borislav Petkov wrote:
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 4ca00474804b..3fbe80066b4e 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -706,6 +706,17 @@ b
On Tue, Nov 08, 2016 at 10:54:52PM +0100, Thomas Gleixner wrote:
> So for now we should fold something like the below into this patch.
Ok, how's that?
---
From: Borislav Petkov
Date: Tue, 8 Nov 2016 16:20:05 +0100
Subject: [PATCH] x86/MCE: Correct TSC timestamping of error records
We did have l
On Tue, 8 Nov 2016, Borislav Petkov wrote:
> On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote:
> > And yes, you should spend the extra cycles. Adding a flags argument to
> > mce_setup() and propagate it through the various callsites shouldn't be
> > that hard and would make the stuf
On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote:
> And yes, you should spend the extra cycles. Adding a flags argument to
> mce_setup() and propagate it through the various callsites shouldn't be
> that hard and would make the stuff obvious instead of obfuscated.
Sure, that's alrea
On Tue, 8 Nov 2016, Borislav Petkov wrote:
> On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote:
> > That does not make any sense. Where is m.tsc initialized? I couldn't find
> > any place which does, except this and the conditional clear farther down in
> > that function.
>
> mce_gat
On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote:
> That does not make any sense. Where is m.tsc initialized? I couldn't find
> any place which does, except this and the conditional clear farther down in
> that function.
mce_gather_info->mce_setup does
m->tsc = rdtsc();
And we do
On Tue, 8 Nov 2016, Borislav Petkov wrote:
>
> Also, this fixes another bug where machine_check_poll() would clear
> mce.tsc unconditionally even if we requested precise MCP_TIMESTAMP
> logging.
> @@ -713,7 +713,6 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
> *b)
>
> This still preserves the precise TSC timestamp in intel_threshold_interrupt().
Yup - this looks right.
Acked-by: Tony Luck
-Tony
On Mon, Nov 07, 2016 at 06:37:50PM +, Luck, Tony wrote:
> Also to me ... and I think that's what used to happen (or at least was the
> intent).
How's that?
This still preserves the precise TSC timestamp in intel_threshold_interrupt().
---
From: Borislav Petkov
Date: Tue, 8 Nov 2016 16:20:05
> One other possibility would be to use ->time and write ->tsc *only*
> when exact - i.e., in the handler - and this is then enough info about
> timing.
>
> ->time will give you somewhere around where it happened and ->tsc - only
> if set - will give you exact, well, *timestamp* :)
>
> This sounds
On Mon, Nov 07, 2016 at 05:48:46PM +, Luck, Tony wrote:
> > So, get rid of all that and simply log an MCE with a TSC value always.
> > Simplifies the code a bit too.
>
> I'm not necessarily opposed to this ... but there was once some logic behind
> when
> logged TSC, and when we didn't. Esse
> So, get rid of all that and simply log an MCE with a TSC value always.
> Simplifies the code a bit too.
I'm not necessarily opposed to this ... but there was once some logic behind
when
logged TSC, and when we didn't. Essentially we wanted the TSC when we were
logging from #CMCI or #MC be
Whoops,
one more:
---
From: Borislav Petkov
Date: Sat, 5 Nov 2016 12:47:03 +0100
Subject: [PATCH] x86/MCE: Remove MCP_TIMESTAMP
MCP_TIMESTAMP controls whether current TSC value should be added to
the MCE record. Most of machine_check_poll() callers supply it, except
__mcheck_cpu_init_generic
14 matches
Mail list logo
