From nobody Sun Feb 8 14:10:47 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 83B4BC001DF for ; Sat, 29 Jul 2023 01:16:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237131AbjG2BQT (ORCPT ); Fri, 28 Jul 2023 21:16:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233297AbjG2BQP (ORCPT ); Fri, 28 Jul 2023 21:16:15 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E116D3AA8 for ; Fri, 28 Jul 2023 18:16:14 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1bb982d2572so17448605ad.0 for ; Fri, 28 Jul 2023 18:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690593374; x=1691198174; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=OXHhc2U25Tn9jZSaAqLCulQOLba1UW3VXuih6bIvn0s=; b=Tod3zMqUpSYaMSjMntQET7ADtNMiYMgbBq1at6tAEQOFQg+AzH1AB/EPsntvDm5vNj EIG9W/6ReBz3I+JF0tX8SPTOlSXnEzx9ES1GjZQ1n/MoCOi0fTE2yochXFZoYOjwC6mc U3t5LNtMvj5DqqX4aJ80m3rhTwam3UPQTo2VgxfpkXQkLR7j/mmDbfm7nz5BPfC0DIRw ipi5tkLT3PhkVV1UrAy//YPPYzAiTfYSNf2NW4oExuekrUxEKRzNGrgzOAYZyTstIeTY SHF0J2p3TR7x0+vKZfwMp/3jlFMAB27g/khgrIS61KbP9aelsIKxNogzIgGACNWWhEod n7PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690593374; x=1691198174; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OXHhc2U25Tn9jZSaAqLCulQOLba1UW3VXuih6bIvn0s=; b=MdSZurcqWqPKUmhl2gRiJSDWFWjldXNj1mj9LGbqQ7BRa3kIDyssRrDrATY1UqI8hF EkIcvXdCCooHyNh0cYdyGPzUI9oOEZw/l4D0JXA46h91B9yrwOTKyzpwJgktKEi09UZA Ms5RPJRaULrbXPiHRxaaXyA+PNLmEBNaD4GEBGwQsO4IjowRukFGBS29AVfDExq3e2Wc Y9W8Ma/Yl2LPen+XRre3mbUsk3wB7KnFt1No5cmdybFd8a1SIH023v1cl+kt7DS/hwxM gEfw8YezfuKByIF1JSVkjv/bvDxy3GXyr9/QHlDNPgIlrE/gUsPfSLLczgmCVxCad4Fx viKw== X-Gm-Message-State: ABy/qLZ5JZLfvWIzTKd2MCJcwddXTcRavSWODfBaHGeNPRnnS/bpG4QG RrF123MZ3UZ+u1lkchDqT8bNghfkDz8= X-Google-Smtp-Source: APBJJlH7vCkGKQZKjpj0ik6iY2LhHM7ilq1KS/soeEeTq5p/PnpLaOaPR70bJynHLI3xqkpO2y/gKTOUAlI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e74b:b0:1b8:a56e:1dcc with SMTP id p11-20020a170902e74b00b001b8a56e1dccmr11826plf.13.1690593374418; Fri, 28 Jul 2023 18:16:14 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 28 Jul 2023 18:15:48 -0700 In-Reply-To: <20230729011608.1065019-1-seanjc@google.com> Mime-Version: 1.0 References: <20230729011608.1065019-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog Message-ID: <20230729011608.1065019-2-seanjc@google.com> Subject: [PATCH v2 01/21] KVM: nSVM: Check instead of asserting on nested TSC scaling support From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Check for nested TSC scaling support on nested SVM VMRUN instead of asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO has diverged from KVM's default. Userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking KVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd] Call Trace: enter_svm_guest_mode+0x114/0x560 [kvm_amd] nested_svm_vmrun+0x260/0x330 [kvm_amd] vmrun_interception+0x29/0x30 [kvm_amd] svm_invoke_exit_handler+0x35/0x100 [kvm_amd] svm_handle_exit+0xe7/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x45ca1b Note, the nested #VMEXIT path has the same flaw, but needs a different fix and will be handled separately. Fixes: 5228eb96a487 ("KVM: x86: nSVM: implement nested TSC scaling") Cc: Maxim Levitsky Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/nested.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 96936ddf1b3c..0b90f5cf9df3 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -695,10 +695,9 @@ static void nested_vmcb02_prepare_control(struct vcpu_= svm *svm, =20 vmcb02->control.tsc_offset =3D vcpu->arch.tsc_offset; =20 - if (svm->tsc_ratio_msr !=3D kvm_caps.default_tsc_scaling_ratio) { - WARN_ON(!svm->tsc_scaling_enabled); + if (svm->tsc_scaling_enabled && + svm->tsc_ratio_msr !=3D kvm_caps.default_tsc_scaling_ratio) nested_svm_update_tsc_ratio_msr(vcpu); - } =20 vmcb02->control.int_ctl =3D (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) | --=20 2.41.0.487.g6d72f3e995-goog