Received-SPF: pass (google.com: domain of linux-kernel+bounces-84822-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: kvm@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>
Cc: Li RongQing <lirongqing@baidu.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] KVM: x86: Fix KVM_FEATURE_PV_UNHALT update logic
Date: Wed, 28 Feb 2024 11:18:34 +0100
Message-ID: <20240228101837.93642-1-vkuznets@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Guest hangs in specific configurations (KVM_X86_DISABLE_EXITS_HLT) are 
reported and the issue was bisected to commit ee3a5f9e3d9b ("KVM: x86: Do
runtime CPUID update before updating vcpu->arch.cpuid_entries") which, of
course, carries "No functional change intended" blurb. Turns out, moving
__kvm_update_cpuid_runtime() earlier in kvm_set_cpuid() to tweak the 
incoming CPUID data before checking it wasn't innocent as 
KVM_FEATURE_PV_UNHALT reset logic relies on cached KVM CPUID base which
gets updated later.

I was not able to reproduce the issue with QEMU myself so I wrote a
selftest to show the problem.

Vitaly Kuznetsov (3):
  KVM: x86: Introduce __kvm_get_hypervisor_cpuid() helper
  KVM: x86: Use actual kvm_cpuid.base for clearing KVM_FEATURE_PV_UNHALT
  KVM: selftests: Check that KVM_FEATURE_PV_UNHALT is cleared with
    KVM_X86_DISABLE_EXITS_HLT

 arch/x86/kvm/cpuid.c                          | 42 ++++++++++++-------
 .../selftests/kvm/x86_64/kvm_pv_test.c        | 42 +++++++++++++++++++
 2 files changed, 68 insertions(+), 16 deletions(-)


base-commit: 0cbca1bf44a0b8666c91ce3438f235c6fe70fbf1
-- 
2.43.0