Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp4543985pxb; Wed, 20 Apr 2022 05:32:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVByDdQqDAGvgUj3/j0UwXhDD4+ukY0M9dCGz32tv4M1znW9MuDXiVB2xF+yE2L7oETvEQ X-Received: by 2002:a63:4642:0:b0:398:b6b9:5f45 with SMTP id v2-20020a634642000000b00398b6b95f45mr19527156pgk.518.1650457941431; Wed, 20 Apr 2022 05:32:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650457941; cv=none; d=google.com; s=arc-20160816; b=DBJOliJ1e22cmto8aeuTQ9xwYHfquI4Ap0k0u0GB74RkF3n6P5UPixjGBCRTZ29NRv HlplUtzOvtkaBEacAplAblB6+BWZ74hRmEBqWOT1mjPglBlHfDScoIzZXDaforqJeIC+ +/FtjbgcyQ/zRvnrU8mEJxTQuSDz9imYDechTgziRumErLUeZwO4y6fr1hO4Wm1Z+BzD +UmYLLsgozQ13HOusw6hW5RNnHWxmlH+LROh/3g5Mkk/LfdLff2h+w4Zb/gTmm36zIgq ueBb3kzAaJCmQpDFlvrPaLYluhoUL7f/8vebUYbTiWulsUWCPzwR4kZbw3yzeUrXujBk gspA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=QhAC2l6ujcHZ1rCzNEs79JUoNr3kzC/rclLKScnTg/c=; b=Zx2zGGTeNrzBE412I+PCnkg6BvqAIn8MRtqKSjgxRiRguVq2DKgoP3vYN5zKzRv7u6 unoGZkChLhbGm5L8VHyMtrQIwTwxv7U07+8kKLRQttdnkqe4PjtDBIUZiCX+jmYA9wp0 cQ4G3UML6Nj3pkX9IstiG43zWQC26pD973Npt4SGxj6klmU4uwSWtduX4JfkvYKl2Svf dP27O8BjZ34Vh2bkO1O7FPVcYNcDIpLbLn15w7v0rGzV6RLMA3UcZvovBEM12URWafoP aUpwIBiJCUYj4B8oiwZByTdtSrGjF4QjQj9WRO/oBg/DoF3cjY4vKoLgp/n/WrQzEOgu 111w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VV+qmhDL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u185-20020a6385c2000000b003aa7a26283fsi500327pgd.7.2022.04.20.05.32.04; Wed, 20 Apr 2022 05:32:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VV+qmhDL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354491AbiDSQSi (ORCPT + 99 others); Tue, 19 Apr 2022 12:18:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346527AbiDSQSh (ORCPT ); Tue, 19 Apr 2022 12:18:37 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD9BF38BCE; Tue, 19 Apr 2022 09:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650384954; x=1681920954; h=from:to:cc:subject:date:message-id; bh=iMKoQZDObCSA8eZswz4OYIjDeRXrAucqZSnlpOy9fR0=; b=VV+qmhDLBK8i6F5Bsfyt05pOhPbXnlXJujWGsoFVnH4nnL8Cu0ShASk9 o3HTqFbtNKFnW8wAbDF4/evNtq/WwpASw+AmXYBVNp0SSD/tFuHc6MzjY u/ij42LxMI9GL4Hr9R0FdUwZ1xvWLAbI/swUHO1020QUUDKDuc6mgLSLv BqgnVsE6Nxg7qT9On0MfqFYjiBhk3KOv92mpZuUO/MdlF3eU2QcJTGW+p sMzq6B+io+h7beXlUsHwXDoqlkO4IIKW4yxkrEeyBQ1isuYCk87gFYYcb WClAqvM6BlfCE0LonHo2nAPhgrXQZ80LMVk1/3pYWrD1tJINciXWHpLfU w==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="245697303" X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="245697303" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 09:15:54 -0700 X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="529374607" Received: from arthur-vostro-3668.sh.intel.com ([10.239.13.120]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 09:15:46 -0700 From: Zeng Guang To: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, Dave Hansen , Tony Luck , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , Kai Huang , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , David Hildenbrand Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Robert Hu , Gao Chao , Zeng Guang Subject: [PATCH v9 7/9] KVM: Move kvm_arch_vcpu_precreate() under kvm->lock Date: Tue, 19 Apr 2022 23:44:09 +0800 Message-Id: <20220419154409.11842-1-guang.zeng@intel.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org kvm_arch_vcpu_precreate() targets to handle arch specific VM resource to be prepared prior to the actual creation of vCPU. For example, x86 platform may need do per-VM allocation based on max_vcpu_ids at the first vCPU creation. It probably leads to concurrency control on this allocation as multiple vCPU creation could happen simultaneously. From the architectual point of view, it's necessary to execute kvm_arch_vcpu_precreate() under protect of kvm->lock. Currently only arm64, x86 and s390 have non-nop implementations at the stage of vCPU pre-creation. Remove the lock acquiring in s390's design and make sure all architecture can run kvm_arch_vcpu_precreate() safely under kvm->lock without recrusive lock issue. Suggested-by: Sean Christopherson Signed-off-by: Zeng Guang --- arch/s390/kvm/kvm-s390.c | 2 -- arch/x86/kvm/x86.c | 2 +- virt/kvm/kvm_main.c | 10 ++++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index 156d1c25a3c1..5c795bbcf1ea 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -3042,9 +3042,7 @@ static int sca_can_add_vcpu(struct kvm *kvm, unsigned int id) if (!sclp.has_esca || !sclp.has_64bscao) return false; - mutex_lock(&kvm->lock); rc = kvm->arch.use_esca ? 0 : sca_switch_to_extended(kvm); - mutex_unlock(&kvm->lock); return rc == 0 && id < KVM_S390_ESCA_CPU_SLOTS; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 0c0ca599a353..277a0da8c290 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11168,7 +11168,7 @@ static int sync_regs(struct kvm_vcpu *vcpu) int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id) { - if (kvm_check_tsc_unstable() && atomic_read(&kvm->online_vcpus) != 0) + if (kvm_check_tsc_unstable() && kvm->created_vcpus) pr_warn_once("kvm: SMP vm created on host with unstable TSC; " "guest TSC will not be reliable\n"); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 70e05af5ebea..d719a15df17f 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3731,13 +3731,15 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id) return -EINVAL; } + r = kvm_arch_vcpu_precreate(kvm, id); + if (r) { + mutex_unlock(&kvm->lock); + return r; + } + kvm->created_vcpus++; mutex_unlock(&kvm->lock); - r = kvm_arch_vcpu_precreate(kvm, id); - if (r) - goto vcpu_decrement; - vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL_ACCOUNT); if (!vcpu) { r = -ENOMEM; -- 2.27.0