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

Peter Hornyack
2015-11-13T17:49:27Z

On Fri, Nov 13, 2015 at 1:42 AM, Paolo Bonzini <pbonzini@redhat.com> 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.

> ----------------------------------
> CRITICAL_STRUCTURE_CORRUPTION (109)
> 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 http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
> 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

Peter