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. > ---------------------------------- > 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html