From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933048AbbKMRtt (ORCPT ); Fri, 13 Nov 2015 12:49:49 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:32926 "EHLO mail-yk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754364AbbKMRtr (ORCPT ); Fri, 13 Nov 2015 12:49:47 -0500 MIME-Version: 1.0 In-Reply-To: <253597133.12158605.1447407774121.JavaMail.zimbra@redhat.com> References: <1447336157-3122-1-git-send-email-pbonzini@redhat.com> <1447336157-3122-2-git-send-email-pbonzini@redhat.com> <253597133.12158605.1447407774121.JavaMail.zimbra@redhat.com> From: Peter Hornyack Date: Fri, 13 Nov 2015 09:49:27 -0800 Message-ID: Subject: Re: [PATCH] KVM: x86: expose MSR_TSC_AUX to userspace To: Paolo Bonzini Cc: kvm list , linux-kernel@vger.kernel.org, Radim Krcmar , stable@vger.kernel.org, Feng Min , Eric Northup Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 13, 2015 at 1:42 AM, Paolo Bonzini 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