From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C3561CEE8E for ; Tue, 1 Oct 2024 23:49:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727826570; cv=none; b=g8VXoHXWCRHfToUaIDN9sUBiGa6nb9/VzJcJLz/o8A/9D5DNzSovnn/ERAKyhu4CAG1Iz7NVAuly8+L7enZkmFaAbuhqjqWwxUlSOvsSXBvM69Z0OkphvlvG/2+JUOgKwCfQ8OCovN/Fc9ntPEj/kdt0AiYdY39ji+jB5YS3q14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727826570; c=relaxed/simple; bh=6OLByul/iGB+FqFJYTFr0DVFRYD1IdpL6JZPzz4PPyQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=DHUDhj+z1o6UPgLIdQAtT7VeSDmSSkIfnF587kXanEwGdzsrDPmIiskFB9J4V4k7YItoLGZohE9DgC5S6pnzD3QaQdsrweTwmBA+CQBx8QTp/i9Lf5wVMBIjBLSgvDIpdT815UC5qFUt+zzBbyTcDQ33NeiG1GT3h2g4rLcTYMU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FfedSVCd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FfedSVCd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B816CC4CEC6; Tue, 1 Oct 2024 23:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727826569; bh=6OLByul/iGB+FqFJYTFr0DVFRYD1IdpL6JZPzz4PPyQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FfedSVCdpHZ7V4cDtMcE6SuYlaFLQ80EK1v0rFkPge2LCofNw0AiDV6ecDw8PAjTH RlOc8eWiiTJd2EizAk9s/KYOOn7UDQA7d/sd8yJM/Wnzh5QhRfAK3tdInNW3A7m/e8 1wgT0rN9aDiWBp83xCs01ySGeNniN2cGAuFFaJXx406ewcnkNo+EYWgc48OOxyyc6/ RTg8KKCb8B1XaorBravRJBPrUCajd2qEPp7PiCqkLzaiiM/XzedmacFx6zhWERIysE kU9g8Ys0C0jI7Jj1vkl5mb2UGvoo2oqbT5uI8i9TsI15sLN4tlkD40P+vxhN+Dqm3I Bq74nCApvweBw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1svmcR-00Gua0-CY; Wed, 02 Oct 2024 00:49:27 +0100 Date: Wed, 02 Oct 2024 00:49:27 +0100 Message-ID: <86cykj75a0.wl-maz@kernel.org> From: Marc Zyngier To: Sean Christopherson Cc: Oliver Upton , kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH 3/3] KVM: arm64: nv: Punt stage-2 recycling to a vCPU request In-Reply-To: References: <20241001001709.1303668-1-oliver.upton@linux.dev> <20241001001709.1303668-4-oliver.upton@linux.dev> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: seanjc@google.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 02 Oct 2024 00:28:18 +0100, Sean Christopherson wrote: > > On Tue, Oct 01, 2024, Oliver Upton wrote: > > Hey, > > > > sidebar: I was a bit confused by the diff for a second, since it looks > > like your email client lowercased some stuff :) > > Wasn't my mail client, it was PEBKAC. I copy+pasted a large chunk in Vim because > I wanted to pull in the changelog (which I had deleted from my response), but then > I changed my mind, and in doing so I managed to fat-finger something that converted > everything to lowercase. And yeah, it confused me too. > > > > > out: > > > > + if (s2_mmu->pending_unmap) > > > > + kvm_make_request(kvm_req_nested_s2_unmap, vcpu); > > > > > > If I followed everything correctly, I don't think a request is needed. the > > > request will never be cross-vCPU, and each vCPU holds a reference to the MMU, so > > > the MMU can't be recycled, i.e. pending_unmap is guaranteed to be relevant to the > > > vCPU's usage of the MMU. More thoughts below in check_nested_vcpu_requests(). > > > > I'm (ab)using the request to prevent the vCPU thread from actually > > entering the VM without first having done the laundry. We have other > > examples of strictly per-vCPU tasks that are tracked with a request so > > this doesn't stick out that much. > > > > Otherwise we'd need an open-coded check in kvm_vcpu_exit_request() to > > catch a 'dirty' MMU or take a pin on it from the point we check the > > dirtiness to the point we disable preemption. > > Ewww, because kvm_arch_vcpu_put() puts the nested stage-2 when the vCPU is > scheduled out. Mostly out of curiosity, why? 99.9% of the time, the vCPU will > be scheduled back in. Because s2 MMU structures are a scarce resource. and other vcpus could have the opportunity to make use of an unused slot. > Now that vcpu->scheduled_out is a thing, retaining the nested s2 MMU should be > quite straightforward. kvm_arch_vcpu_destroy() would need to put the MMU, but > that should also be straightforward. This code long predates scheduled_out, and I don't think this brings much to the table. If the vcpu comes back quickly, it will find its toys where it left them. If not, someone else will have borrowed them, and it will have to pick new ones. It isn't any different from TLBs, which s2 MMUs model. M. -- Without deviation from the norm, progress is not possible.