From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3FC2332EDA for ; Mon, 1 Dec 2025 15:55:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764604549; cv=none; b=eBA+TvgCYIUfu2ZGr/2s3Z2QhQnkTRLdpVAJXisZlh7X3sV0NCXKbjPL6fLSAtAMYCY2XxZzPVRP+mjq1K0LSaALDxp6nhnCa8RFSsPOGCShyD73mkzaYu2MlGoM80fb9LzZMqeCqMs3bOCPMZKJtIQJt3nbB8D7esXLVC/7/bk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764604549; c=relaxed/simple; bh=dYdbGSq1hyaFcK0Vbnfam/5HkvnPvCtpmqz5zFQEQRU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=j5+5lmIbv3RoHnHQOeRJk5LNp8Uj1fTWYbjeKlVFXXhdPvD/EGPbmpR8Y2+MWGjU6CPh/fE4i0JhtPEWkKhZsdn1pSoLS+4cyRQ4ElRwCc0XZNMdcXr1ExJgaxMjPvZwtKLVRWJE00eBxygzVGwBTb/9uWfNiWKljMS22eOoIOI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ye6IveXn; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ye6IveXn" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-7b9090d9f2eso7203554b3a.0 for ; Mon, 01 Dec 2025 07:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1764604546; x=1765209346; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4Ojq6WP276k7ulL9n/nH2NWkQuA4BiAIh8qTVVTbn9M=; b=ye6IveXnVs4CDuLtYir996MjXQ1yd1ff9QWu5neXcsTrnPO/K1Y2kSzolPhPP7hOw6 JXZGx5X8BYRQPfJ/AazJQNOGA8/VwUUTnvNE0tREShUsJPKQqsxeFHbNoIys83MJ8lhw uWhOGMBY1RqmTTNsehAzAoOGFiIMLK8dHy9bhoFAp9uS6O5UnDl76+SJi7+K3FT1KCkH X4JAsmBLfmAaXwb4rQx5/nZF6aqBoDftR6mTyhNaCzZfdWTBwLAAaS4wPhPu++dF3Cnb M2IxQIuVpfk63Ju9U6Ww1oqIRKkEUUNWmffIpIWfUsH7u+aRHNlIMWIE72K89WsstD4E OvoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764604546; x=1765209346; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4Ojq6WP276k7ulL9n/nH2NWkQuA4BiAIh8qTVVTbn9M=; b=mcp0yua3O7jEa2HKn+o6Ne3T4UzwPDUrI/rHdkf9mYoH5y0N0UrSLLFYR8vLCmTFut LCJtXnHhD9HnubSluaBXCa1JZ+HkGX67aqW/+E//bscHz4yDRTJ0NNMpNMaqdsNSPF0X oY3kPbNw4pYVf2Lh87aKEN66c7lzXKlfzI0m7L4UJNbTBV57nLrP9scLCZQ0JHmLJbbe wkjr53VGodyl7ZjEn8frNGRL9NqpUfP8U4GEUzlbUHhYbfX5Pw56aZIe52oDvUgtxuns NyW0zKMgGJ7J9T+Yhi4K1k0/ivEhfHH2juKH4dgQJHOyWTrOl3NJPZ8qL9Fp9YTw851x Lhew== X-Forwarded-Encrypted: i=1; AJvYcCVKQZWfNaYH9tJ6PJ9laQjQwqDazsw8APxehHCqWGiIZ7QeaZN0Fq0l8zELeh4C9YFXGwblgY+hX1bwZMw=@vger.kernel.org X-Gm-Message-State: AOJu0YzH7Gf78RvCd/ZTpDmnjJDNW3B/vXGQK093oWf4ilOW2gyAvuGc 4/tuBbkZo8Rau4UEy7jT5hgJKMbzAzo4PXMt6K2DvSiuBG2oE5DUBfeQ+9hhi4ctUBYkSt6iFMH 13yaqwg== X-Google-Smtp-Source: AGHT+IHYlsnd6krdSCI3OWnVJ7V1appZkU6hmkhgHr+N2fGX/9NSiltXr3T5N0gnEQ22pw551C85ykj99i0= X-Received: from pgve25.prod.google.com ([2002:a65:6499:0:b0:bc3:cbd2:e0a1]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6da3:b0:34f:a16f:15ad with SMTP id adf61e73a8af0-3614edd99bemr45418160637.53.1764604545930; Mon, 01 Dec 2025 07:55:45 -0800 (PST) Date: Mon, 1 Dec 2025 07:55:44 -0800 In-Reply-To: <20251128123202.68424a95@imammedo> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20241211013302.1347853-1-seanjc@google.com> <20241211013302.1347853-6-seanjc@google.com> <20251128123202.68424a95@imammedo> Message-ID: Subject: Re: [PATCH 5/5] KVM: x86: Defer runtime updates of dynamic CPUID bits until CPUID emulation From: Sean Christopherson To: Igor Mammedov Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , mlevitsk@redhat.com Content-Type: text/plain; charset="us-ascii" On Fri, Nov 28, 2025, Igor Mammedov wrote: > On Tue, 10 Dec 2024 17:33:02 -0800 > Sean Christopherson wrote: > > Sean, > > this patch broke vCPU hotplug (still broken with current master), > after repeated plug/unplug of the same vCPU in a loop, QEMU exits > due to error in vcpu initialization: > > r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, &cpuid_data); > if (r) { > goto fail; > } > > Reproducer (host in question is Haswell but it's been seen on other hosts as well): > for it to trigger the issue it must be Q35 machine with UEFI firmware > (the rest doesn't seem to matter) Gah, sorry. I managed to handle KVM_GET_CPUID2, so I suspect I thought the update in kvm_cpuid_check_equal() would take care of things, but that only operates on the new entries. Can you test the below? In the meantime, I'll see if I can enhance the CPUID selftest to detect the issue and verify the fix. diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index d563a948318b..dd6534419074 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -509,11 +509,18 @@ static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2, u32 vcpu_caps[NR_KVM_CPU_CAPS]; int r; + /* + * Apply pending runtime CPUID updates to the current CPUID entries to + * avoid false positives due mismatches on KVM-owned feature flags. + */ + if (vcpu->arch.cpuid_dynamic_bits_dirty) + kvm_update_cpuid_runtime(vcpu); + /* * Swap the existing (old) entries with the incoming (new) entries in * order to massage the new entries, e.g. to account for dynamic bits - * that KVM controls, without clobbering the current guest CPUID, which - * KVM needs to preserve in order to unwind on failure. + * that KVM controls, without losing the current guest CPUID, which KVM + * needs to preserve in order to unwind on failure. * * Similarly, save the vCPU's current cpu_caps so that the capabilities * can be updated alongside the CPUID entries when performing runtime