From nobody Sun Feb 8 04:13:19 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8368BC04A94 for ; Tue, 8 Aug 2023 23:21:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230127AbjHHXVC (ORCPT ); Tue, 8 Aug 2023 19:21:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229931AbjHHXVB (ORCPT ); Tue, 8 Aug 2023 19:21:01 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FB7619BC for ; Tue, 8 Aug 2023 16:21:00 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-585fb08172bso74060457b3.2 for ; Tue, 08 Aug 2023 16:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691536859; x=1692141659; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=h31RifgLdWj/uBkkEanO2XNAftVRa4x/sEAr5Du6O7s=; b=3HkpHRvUGz0wWRT9OA2Ov4hn6J6IuWP0KypK80EvpNWkaxvw5xrqpgKSc6cN/pQUeS BTy0QrS4OgiVI2hc16+7oGnfLI3JzDXO3tZCfX3Ga31R7/IEG9HQVP49xveMYR2Sy096 t+cBlH5TzUA4S+paOIda4LbGc2Mp/7c3DM7mNrOQuHOZ1W0Zhu/4Z4QjMaZuOF6vlKYt rJ3Wfol3W8ZzlZQEZ4/84C3qOsIssVV4BC+kcMmhQ28SBdY+slKFRYau7RtFnSaRpGUR y3JbWRiPUgHG0pZlHoQ8PusqX5v0e3hDdT90UCtfbztjJo/RI5+6Waht9EJSCMWPjTTM mEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691536859; x=1692141659; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h31RifgLdWj/uBkkEanO2XNAftVRa4x/sEAr5Du6O7s=; b=eSP5oaBRGMYLb2zBCnRkL9GcdKnZHwG+YUD1E2Hcc56X3sfzn9hbDKY4p2OkazjxtR 8KGKrmfiTw/OUUhSNGhvgRoVpkarqfZ0c4FB2GsFyNPX8tpBLtg0Cv88CYabaXHM8khx TVCupjmha+wBqSRDhzPhO0NbvFWKn8LuhWdyIPsX6VBIg2SyeddzYDH9I9OggZD1cho0 cJRSPRjvrPnfJ3omVTWbooEpyS2FbQxvJIPzWvt/H8kU2sgmOHbZhkVOo+5c1cVYKvig a9fIBHxhnWk5Zqd9I9m8G1Rh3MoOf+srmK3Ibxg7skmCSIS2qVppQu2/0tQ95uSCcFBd /azA== X-Gm-Message-State: AOJu0Yy3Tn3O1EHTip50YWIkXyT2lojfnEUKgoXVGVCxPhOL7+J6vp8h +ajhdylj4rQtkMzy0ozZ4koWTdEowXs= X-Google-Smtp-Source: AGHT+IFacH1gV3EFOlAiXA5r13GnRn0tz4keJlj3GrBkHHQsxR2ixuO7JpkZvWdwq6OLOMIvvXHRz6bdj+I= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:b707:0:b0:586:a689:eb69 with SMTP id v7-20020a81b707000000b00586a689eb69mr25680ywh.2.1691536859434; Tue, 08 Aug 2023 16:20:59 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 8 Aug 2023 16:20:57 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.640.ga95def55d0-goog Message-ID: <20230808232057.2498287-1-seanjc@google.com> Subject: [PATCH] KVM: x86: Remove WARN sanity check on hypervisor timer vs. UNINITIALIZED vCPU From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yikebaer Aizezi Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop the WARN in KVM_RUN that asserts that KVM isn't using the hypervisor timer, a.k.a. the VMX preemption timer, for a vCPU that is in the UNINITIALIZIED activity state. The intent of the WARN is to sanity check that KVM won't drop a timer interrupt due to an unexpected transition to UNINITIALIZED, but unfortunately userspace can use various ioctl()s to force the unexpected state. Drop the sanity check instead of switching from the hypervisor timer to a software based timer, as the only reason to switch to a software timer when a vCPU is blocking is to ensure the timer interrupt wakes the vCPU, but said interrupt isn't a valid wake event for vCPUs in UNINITIALIZED state *and* the interrupt will be dropped in the end. Reported-by: Yikebaer Aizezi Closes: https://lore.kernel.org/all/CALcu4rbFrU4go8sBHk3FreP+qjgtZCGcYNpSiE= XOLm=3D=3DqFv7iQ@mail.gmail.com Signed-off-by: Sean Christopherson Reviewed-by: Paolo Bonzini --- arch/x86/kvm/x86.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index a6b9bea62fb8..fa7eeb45b8e3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11091,12 +11091,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) r =3D -EINTR; goto out; } + /* - * It should be impossible for the hypervisor timer to be in - * use before KVM has ever run the vCPU. + * Don't bother switching APIC timer emulation from the + * hypervisor timer to the software timer, the only way for the + * APIC timer to be active is if userspace stuffed vCPU state, + * i.e. put the vCPU into a nonsensical state. Only an INIT + * will transition the vCPU out of UNINITIALIZED (without more + * state stuffing from userspace), which will reset the local + * APIC and thus smother the timer anyways, i.e. the APIC timer + * IRQ(s) will be dropped no matter what. */ - WARN_ON_ONCE(kvm_lapic_hv_timer_in_use(vcpu)); - kvm_vcpu_srcu_read_unlock(vcpu); kvm_vcpu_block(vcpu); kvm_vcpu_srcu_read_lock(vcpu); base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c --=20 2.41.0.640.ga95def55d0-goog