From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754969AbdC1Mkk (ORCPT ); Tue, 28 Mar 2017 08:40:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34640 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753503AbdC1Mkf (ORCPT ); Tue, 28 Mar 2017 08:40:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5617FC05B1E9 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5617FC05B1E9 Subject: Re: [PATCH] kvm/x86/vmx: report KVM_SYSTEM_EVENT_CRASH on triple fault To: Josh Poimboeuf References: <2101391670.8452799.1490687461888.JavaMail.zimbra@redhat.com> <20170328114617.zapicqltmtarv4jt@treble> Cc: rkrcmar@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org From: Paolo Bonzini Message-ID: <1394433d-528a-06c1-6684-74c4c1dd3081@redhat.com> Date: Tue, 28 Mar 2017 14:39:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170328114617.zapicqltmtarv4jt@treble> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 28 Mar 2017 12:39:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/03/2017 13:46, Josh Poimboeuf wrote: > On Tue, Mar 28, 2017 at 03:51:01AM -0400, Paolo Bonzini wrote: >> >>> While debugging a kernel issue, I found that QEMU always reboots when an >>> x86 triple fault occurs, which complicates debugging. QEMU and libvirt >>> have a facility for creating a dump when KVM reports >>> KVM_SYSTEM_EVENT_CRASH. So change the VMX triple fault handler to do >>> that. This gives user space the ability to decide whether to dump, >>> pause, shutdown, or reboot. >> >> You probably want QEMU's -no-reboot option. >> >> Triple faults are already reported to userspace with KVM_EXIT_SHUTDOWN, >> and it's up to userspace to decide what to do with it. This patch cannot >> be applied, because there are guests that do a triple-fault intentionally >> in order to reset the machine. > > Ok. Any idea how to force libvirt to create a dump? It has a > 'coredump-destroy' option, but that only seems to work with 'on_crash': > > https://libvirt.org/formatdomain.html#elementsEvents Probably QEMU, when invoked with -no-shutdown -no-reboot, should treat KVM_EXIT_SHUTDOWN as a panic. I can have a go at it, but note that QEMU is now in hard freeze for the next release, so it will take a while. However you're using libvirt and it doesn't use -no-reboot. It's probably possible for libvirt to use -no-reboot more often. The price would be that if libvirtd crashes and a VM wants to reset, then the VM gets stuck. Alternatively, we could generalize -no-shutdown and -no-reboot to something like: -action reset=stop|restart|quit, poweroff=stop|quit, triple-fault=stop|panic|restart|quit and teach libvirt about it. The current semantics map relatively easily to the new option: | reset | poweroff | triple-fault --------------------------+-------------+------------+------------------- no option | restart | quit | restart -no-shutdown | restart | stop | restart -no-reboot | quit | quit | quit -no-shutdown -no-reboot | stop | stop | stop (panic?) Paolo