Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: IjcWlCbiqXgTJoKu0wf/KWar0x7tikALWGy4P1nB07KDFtxAd/zN0Z8vuoA5k7pA2Wgvf3//I7
 34+If4jgvuXg==
IronPort-SDR: EZaFWLbW8btGXcoTvzeyQT6xjFbceGOJPwKLW6J7q51OFBid7lzF/JjZ5tQm4V+nRUhHp7EQ/B
 axatwRgBhKxQ==
Date:   Tue, 26 May 2020 22:13:55 -0700
From:   Sean Christopherson <sean.j.christopherson@intel.com>
To:     Brad Campbell <lists2009@fnarfbargle.com>
Cc:     Maxim Levitsky <mlevitsk@redhat.com>, kvm@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: KVM broken after suspend in most recent kernels.
Message-ID: <20200527051354.GL31696@linux.intel.com>
References: <1f7a85cc-38a6-2a2e-cbe3-a5b9970b7b92@fnarfbargle.com>
 <f726be8c-c7ef-bf6a-f31e-394969d35045@fnarfbargle.com>
 <1f7b1c9a8d9cbb6f82e97f8ba7a13ce5b773e16f.camel@redhat.com>
 <a45bc9d7-ad0b-2ff0-edcc-5283f591bc10@fnarfbargle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a45bc9d7-ad0b-2ff0-edcc-5283f591bc10@fnarfbargle.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, May 25, 2020 at 09:15:57PM +0800, Brad Campbell wrote:
> >When you mean that KVM is broken after suspend, you mean that you can't
> >start new VMs after suspend, or do VMs that were running before suspend
> >break?  I see the later on my machine. I have AMD system though, so most
> >likely this is another bug.
> >
> >Looking at the commit, I suspect that we indeed should set the IA32_FEAT_CTL
> >after resume from ram, since suspend to ram might count as a complete CPU
> >reset.
> >
> 
> One of those "I should have clarified that" moments immediately after I
> pressed send.  I've not tried suspending with a VM running. It's "can't start
> new VMs after suspend".

Don't bother testing suspending with a VM, the only thing that will be
different is that your system will hang on resume instead when running a
VM.  If there are active VMs, KVM automatically re-enables VMX via VMXON
after resume, and VMXON is what's faulting.

Odds are good the firmware simply isn't initializing IA32_FEAT_CTL, ever.
The kernel handles the boot-time case, but I (obviously) didn't consider
the suspend case.  I'll work on a patch.