From mboxrd@z Thu Jan 1 00:00:00 1970 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F2B05C021B2 for ; Tue, 25 Feb 2025 14:45:04 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Z2L3z3QZdz30Tm; Wed, 26 Feb 2025 01:45:03 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2607:f8b0:4864:20::1049" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1740494703; cv=none; b=MVQLZ6EVUe1RZFckTyDob399KwOw9szvtUGRTyLex4ZxAwvh2csGmdDP4Cx1cNSmruarEToIfiIJE5c5zy+qTWhG+MHtFW9DvVX8Y9PnvUigb4MvdA5lULPvFneL7MBO9At/X15PvN2sNSrDkXQrZtIu1vLihIc5EVTKafxsqIQxTBAzJGsneoFQFoj6Iz5vBrbwTC7YOwmXodvzxjoxwogNGRRpTfjRa3oM3UZSg0v89QG7ypZlFIi38w1t1W67haj0q2z72NI0kclRWyu6b90Un/EaX33knSQD9/N+2BgrWMBYOcjnIyhDo0QezoWBB/t4DmTieY4JASzxO03Q7g== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1740494703; c=relaxed/relaxed; bh=NffzjCDpuTmdNSnLuEbvoNsdUgp9uFncpWixfvcrqX0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=c3nHWR3K6MMagMjpa6AsPxxG1AjWGaDMOMlkHJ4I/mKpnaHNyuslQEidN7TpT+66A4xwo/XVL3GK2PhkKazzSokBYXRTdBHCsvrfiMaijliRIiKCibNcbt8vbJ6ynmpKjK0FNsr9M1a8YsS7RGbVH5nYeRHWEIwGCorIGrMkbcaM5xchw1Loa+Z9SqRvjbqodT1hTicInCTlhOxbGozZCkcumRvmHgybAUsR0/CElmSu3UoyIGdMHoEtNmvb2CGka3C56RSylEc0m61MO54VC3V/h74j5aA3PHTz1SZ2XTEdBVCzujVUQ+XmQJYWpF7VroE9NDGgkkPmd6yaKdfiXw== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=XYd0BUMM; dkim-atps=neutral; spf=pass (client-ip=2607:f8b0:4864:20::1049; helo=mail-pj1-x1049.google.com; envelope-from=3bne9zwykdfch3zc815dd5a3.1dba7cjmee1-23ka7hih.doaz0h.dg5@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=XYd0BUMM; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::1049; helo=mail-pj1-x1049.google.com; envelope-from=3bne9zwykdfch3zc815dd5a3.1dba7cjmee1-23ka7hih.doaz0h.dg5@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Z2L3y3lxWz30T9 for ; Wed, 26 Feb 2025 01:45:02 +1100 (AEDT) Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-2fc17c3eeb5so11780548a91.1 for ; Tue, 25 Feb 2025 06:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740494700; x=1741099500; darn=lists.ozlabs.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=NffzjCDpuTmdNSnLuEbvoNsdUgp9uFncpWixfvcrqX0=; b=XYd0BUMMBF14nXTghyP7DQ9wgkAY2e104cUuNpEXsM0JVmErmSeWiu9RWZ/JovD4ce 2Qt/Xp3bFgfQNfaeZWKck4AfB834mZP6n3WBlp5SYwKJm0xr4v9PRfMjDijYfLhxJR00 izh13sWB1P79BoXpWgT1GdwYvPK79nRmcB6POyku3I72UKQwW2GzFg2pNo3ZMdvcR4ob f348D7i4HsCbnH2EFj+vYfHlCWkbVmDiaXRaGXtSjfVFb6kMFw8eeVpOeiZ4HX8nyEXL v1rMDxQGD7rRWhGfi8QCqljipdY6kp+wsmleXu+8t0a3UvSQCWCjEihFQ2Wvnzok9HSu Gcew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740494700; x=1741099500; 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=NffzjCDpuTmdNSnLuEbvoNsdUgp9uFncpWixfvcrqX0=; b=rM8Y6srhVqpORqlqkcSFyIABsvzKyYzKOv0KKXIPqvM5tqbF7/34RPyjvYzUgd1D2k 8WqBELtQ8G/+MJ3Ocop0oEY66EjTR/eMX2+gFYWgJBh5PtjxVrcVWPXW1iGnqOuPSm56 rVBj07JsT2NFUVINfHhjyTyxO2KTQuGggn54TsMvwiL3Ct/Pr7FGx4f1DSyiIeS9p6N2 ftKCs1SYFZEKerG+3TRPhmDr+SpvlURwsmOgENmKAUVZleU05j0wMXb/b6c0GypYk+6t cPXPvrGvOq3G8K+JBmSOmc6WZS+xZmTdFri2QgT+a+cqsQ+bCi0xLTmGYW8uuPcVt6aE IoFQ== X-Forwarded-Encrypted: i=1; AJvYcCU7DqYNN3RIRo6Ru38B9AezlumRXAOQK1SKv4XCrMQwLs+/0tb9mCoNf4hTrFJN+qTAQ2k0VuK2+9JDPSU=@lists.ozlabs.org X-Gm-Message-State: AOJu0YxV9sTAAEQKbbx51dZOrQNvPgUzgWQfeTY3UZHCNB6/ZpTye5ou GcSBGzgPUPtdwxMUSLKgd79VjPZ4oLciT6sbIHPI3HKrvIOuv2OfrEUwr+bPwJI5+aF7HRh0fqV wAg== X-Google-Smtp-Source: AGHT+IG2KruXetDYoI9qbCSWmcITW+yhg6mxBcrrqoCenX7IkOOc3aJKkHxPw+LBj1f6DGaIHr4WklpxusU= X-Received: from pjh14.prod.google.com ([2002:a17:90b:3f8e:b0:2ea:29de:af10]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:548f:b0:2ee:d7d3:3008 with SMTP id 98e67ed59e1d1-2fce86ae5d0mr31991980a91.12.1740494700343; Tue, 25 Feb 2025 06:45:00 -0800 (PST) Date: Tue, 25 Feb 2025 06:44:58 -0800 In-Reply-To: X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Mime-Version: 1.0 References: <20250224235542.2562848-1-seanjc@google.com> <20250224235542.2562848-5-seanjc@google.com> Message-ID: Subject: Re: [PATCH 4/7] KVM: x86: Don't load/put vCPU when unloading its MMU during teardown From: Sean Christopherson To: Yan Zhao Cc: Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Paolo Bonzini , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Aaron Lewis , Jim Mattson , Rick P Edgecombe , Kai Huang , Isaku Yamahata Content-Type: text/plain; charset="us-ascii" On Tue, Feb 25, 2025, Yan Zhao wrote: > On Mon, Feb 24, 2025 at 03:55:39PM -0800, Sean Christopherson wrote: > > Don't load (and then put) a vCPU when unloading its MMU during VM > > destruction, as nothing in kvm_mmu_unload() accesses vCPU state beyond the > > root page/address of each MMU, i.e. can't possible need to run with the > > vCPU loaded. > > > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kvm/x86.c | 9 +-------- > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 045c61cc7e54..9978ed4c0917 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -12767,13 +12767,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) > > return ret; > > } > > > > -static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu) > > -{ > > - vcpu_load(vcpu); > > - kvm_mmu_unload(vcpu); > > - vcpu_put(vcpu); > > -} > > - > > static void kvm_unload_vcpu_mmus(struct kvm *kvm) > > { > > unsigned long i; > > @@ -12781,7 +12774,7 @@ static void kvm_unload_vcpu_mmus(struct kvm *kvm) > > > > kvm_for_each_vcpu(i, vcpu, kvm) { > > kvm_clear_async_pf_completion_queue(vcpu); > > - kvm_unload_vcpu_mmu(vcpu); > > + kvm_mmu_unload(vcpu); > What about just dropping kvm_unload_vcpu_mmu() here? > kvm_mmu_unload() will be invoked again in kvm_mmu_destroy(). > > kvm_arch_vcpu_destroy() --> kvm_mmu_destroy() --> kvm_mmu_unload(). Ugh, I missed that there's yet another call to kvm_mmu_unload(). I definitely agree with dropping the first kvm_mmu_load(), but I'll do it in a follow-up patch so that all three changes are isolated (not doing the load/put, doing unload as part of vCPU destruction, doing unload only once at the end). And looking at both calls to kvm_mmu_unload(), I suspect that grabbing kvm->srcu around kvm_mmu_destroy() is unnecessary. I'll try cleaning that up as well.