Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <20dcddad9f6c8384c49f9d8ec95a826df35fc92d.camel@redhat.com>
Subject: Re: [PATCH] KVM: x86: enable TDP MMU by default
From:   Maxim Levitsky <mlevitsk@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>,
        Stoiko Ivanov <s.ivanov@proxmox.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        bgardon@google.com, Jim Mattson <jmattson@google.com>
Date:   Wed, 27 Jul 2022 13:22:48 +0300
In-Reply-To: <ffc99463-6a61-8694-6a4e-3162580f94ee@redhat.com>
References: <20210726163106.1433600-1-pbonzini@redhat.com>
         <20220726165748.76db5284@rosa.proxmox.com>
         <ffc99463-6a61-8694-6a4e-3162580f94ee@redhat.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 2022-07-26 at 17:43 +0200, Paolo Bonzini wrote:
> On 7/26/22 16:57, Stoiko Ivanov wrote:
> > Hi,
> > 
> > Proxmox[0] recently switched to the 5.15 kernel series (based on the one
> > for Ubuntu 22.04), which includes this commit.
> > While it's working well on most installations, we have a few users who
> > reported that some of their guests shutdown with
> > `KVM: entry failed, hardware error 0x80000021` being logged under certain
> > conditions and environments[1]:
> > * The issue is not deterministically reproducible, and only happens
> >    eventually with certain loads (e.g. we have only one system in our
> >    office which exhibits the issue - and this only by repeatedly installing
> >    Windows 2k22 ~ one out of 10 installs will cause the guest-crash)
> > * While most reports are referring to (newer) Windows guests, some users
> >    run into the issue with Linux VMs as well
> > * The affected systems are from a quite wide range - our affected machine
> >    is an old IvyBridge Xeon with outdated BIOS (an equivalent system with
> >    the latest available BIOS is not affected), but we have
> >    reports of all kind of Intel CPUs (up to an i5-12400). It seems AMD CPUs
> >    are not affected.
> > 
> > Disabling tdp_mmu seems to mitigate the issue, but I still thought you
> > might want to know that in some cases tdp_mmu causes problems, or that you
> > even might have an idea of how to fix the issue without explicitly
> > disabling tdp_mmu?
> 
> If you don't need secure boot, you can try disabling SMM.  It should not 
> be related to TDP MMU, but the logs (thanks!) point at an SMM entry (RIP 
> = 0x8000, CS base=0x7ffc2000).

No doubt about it. It is the issue.

> 
> This is likely to be fixed by 
> https://lore.kernel.org/kvm/20220621150902.46126-1-mlevitsk@redhat.com/.


Speaking of my patch series, anything I should do to move that thing forward?

My approach to preserve the interrupt shadow in SMRAM doesn't seem to be accepted,
so what you think I should do?

Best regards,
	Maxim Levitsky

> 
> Paolo
>