From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755452AbcB2Ppx (ORCPT ); Mon, 29 Feb 2016 10:45:53 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:38106 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751058AbcB2Ppu (ORCPT ); Mon, 29 Feb 2016 10:45:50 -0500 Subject: Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2] To: Linus Torvalds , Jiri Slaby References: <20160217203730.GA14820@kroah.com> <56CED373.9060603@suse.cz> <56CF4A83.3040408@hurleysoftware.com> <56CF64C9.8050705@hurleysoftware.com> <56CF72EA.9040009@suse.cz> <56D01331.5030401@suse.cz> Cc: Peter Hurley , Greg KH , Linux Kernel Mailing List , Andrew Morton , stable , lwn@lwn.net, Steven Rostedt From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <56D467AA.4060001@redhat.com> Date: Mon, 29 Feb 2016 16:45:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/02/2016 18:12, Linus Torvalds wrote: > It does feel like CPU state corruption - either due to a qemu bug, or > due to some odd trap/interrupt handling bug of ours. > > Or possibly a CPU/microcode bug. You wouldn't happen to run this on an > AMD Piledriver-based CPU with the 0x06000832 microcode? > > Because we do have a pending qemu-related bug-report that turned out > to be a AMD microcode problem with NMI delivery. Looking at that bug > report, it actually looks rather similar - also due to a confused RIP. Just a couple notes about QEMU and KVM... First, if you suspect a QEMU or KVM bug, feel free to Cc me. Second, people generally say "QEMU" because that's what the SMBIOS info says, but it's helpful to distinguish the two. Nowadays it's almost always KVM, but at least Intel was running tests on QEMU's binary translator (no VT-x, no KVM) because it supported SMEP and SMAP long before hardware was common. Similarly, the next version of QEMU should support PKE so perhaps someone will be using it again to play with PKE. Third, suspected QEMU bugs almost always end up being QEMU bugs, but KVM bugs rarely show up as random crashes in a Linux guest. KVM does _really_ little these days unless the host is swapping. (The puzzling aspect of the NMI microcode issue was that it was a plausible KVM bug, but such a KVM bug would have either showed up also on Intel, or if AMD-only also on other kinds of interrupts than NMIs). On the other hand, if your host is swapping and you hit a KVM bug, it's the host that would crash, not the guest. Thanks, Paolo