Re: [PATCH] KVM: x86: expose MSR_TSC_AUX to userspace

From: Peter Hornyack
Date: Fri Nov 13 2015 - 12:49:53 EST

On Fri, Nov 13, 2015 at 1:42 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>> Paolo, under what circumstances (which versions of Windows? Anything
>> special running in the guest?) has this failure happened? I'd like to repro
>> this, I'm not sure if we've observed it before.
> We saw it with migration under Windows 10, nothing special running in the
> guest. It's very hard to reproduce, we've only seen it once but the BSOD
> parameters provided surprisingly good evidence:

Great, thanks for that information and for the patch. I'll let you
know if I successfully reproduce the issue here.

> ----------------------------------
> This bugcheck is generated when the kernel detects that critical kernel code or
> data have been corrupted. There are generally three causes for a corruption:
> 1) A driver has inadvertently or deliberately modified critical kernel code
> or data. See
> 2) A developer attempted to set a normal kernel breakpoint using a kernel
> debugger that was not attached when the system was booted. Normal breakpoints,
> "bp", can only be set if the debugger is attached at boot time. Hardware
> breakpoints, "ba", can be set at any time.
> 3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
> Arguments:
> Arg1: a3a01f58a88e3638, Reserved
> Arg2: b3b72bdefb0f076f, Reserved
> Arg3: 00000001c0000103, Failure type dependent information
> Arg4: 0000000000000007, Type of corrupted region, can be
> ...
> 7 : Critical MSR modification
> ----------------------------------
> Argument 1 and 2 might be related to the old and new value (perhaps some
> kind of hash).
> Argument 3 is not documented either, but the low 32 bits look a lot like
> the MSR_TSC_AUX index. :)
> Paolo

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at