From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [nVMX] With 3.20.0-0.rc0.git5.1 on L0, booting L2 guest results
 in L1 *rebooting*
Date: Thu, 19 Feb 2015 16:01:59 +0100
Message-ID: <20150219150159.GA19057@potion.brq.redhat.com>
References: <20150216204013.GI21838@tesla.redhat.com>
 <54E2D966.9070706@siemens.com>
 <20150217112426.GL21838@tesla.redhat.com>
 <54E4C0FD.4090906@redhat.com>
 <20150219120719.GJ11686@tesla.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, kvm@vger.kernel.org,
	dgilbert@redhat.com
To: Kashyap Chamarthy <kchamart@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:42298 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751605AbbBSPCK (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 19 Feb 2015 10:02:10 -0500
Content-Disposition: inline
In-Reply-To: <20150219120719.GJ11686@tesla.redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2015-02-19 13:07+0100, Kashyap Chamarthy:
> Just did two tests with 3.18:
> 
> (1) Kernel 3.18 on L0 and 3.20 on L1
> 
>     Result: Booting L2 guest causes L1 to reboot, and the same[*] stack
>             trace on L0 (mentioned on this thread previously).
> 
>             But, annoyingly enough, when I did test (2) below, and then
>             switched back to test (1), I don't notice the said stack
>             trace in L0's `dmesg` however many times I boot an L2 guest.
> 
> (2) Kernel 3.18 on both L0 and L1
> 
>     Result: Booting L2 guest causes L1 to reboot, but *no* stack trace
>             on L0

It is WARN_ON_ONCE, so it quite likely happened with 3.18 too.

5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
  This concept is based on the rule that a pending vmlaunch/vmresume is
  not canceled. Otherwise, we would risk to lose injected events or leak
  them into the wrong queues. Encode this rule via a WARN_ON_ONCE at the
  entry of nested_vmx_vmexit.

I wonder if we have broken the invariant since 3.9 ...