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: <ffc99463-6a61-8694-6a4e-3162580f94ee@redhat.com>
Date:   Tue, 26 Jul 2022 17:43:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] KVM: x86: enable TDP MMU by default
Content-Language: en-US
To:     Stoiko Ivanov <s.ivanov@proxmox.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        bgardon@google.com
References: <20210726163106.1433600-1-pbonzini@redhat.com>
 <20220726165748.76db5284@rosa.proxmox.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <20220726165748.76db5284@rosa.proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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).

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

Paolo