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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 90610C43458 for ; Mon, 6 Jul 2026 07:25:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3P8yOozKPJARJM21q75q44Lclkmu0wTSf8D8yqBpx/o=; b=OOXqpcxGpfEIzuSbnSDXHy4EBK MwF8BM+kyU6Da87lbj2JU3/BGUURUSEmTgZolGJ71UsVOarirH7PEj2MeXsKF+q0yn5cmx9wuOZ5B GufXiE1apTm8qlbwcn2Wkfd9xxdAd9M7w+jp+FUkN7u4IAk0/EmYvJ6O7tbGtGQAMeQ6Zf2q6MUrE n7TRhtoLXy+Da3cufROhHCRp278gbgb7WLa5DuU3DB578+86WfRpsGY0MEBhP5GORSfhU4Zqvvy1V 3MOa9yt13myY1Q31n1NPqOm7Edll4NPUbrU2BqMPrgrAU/fzkMupa3pamk861FzrTtn1b0Ja3ztOm J6/+7G3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgdhg-0000000BjBy-2vpT; Mon, 06 Jul 2026 07:25:20 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wgdhe-0000000BjBW-0OZ9 for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2026 07:25:19 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D9C08600BB; Mon, 6 Jul 2026 07:25:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C75E1F000E9; Mon, 6 Jul 2026 07:25:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783322716; bh=3P8yOozKPJARJM21q75q44Lclkmu0wTSf8D8yqBpx/o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=TNPFh48fTeuufjfskbih05Phrn1j7m20l/pafVdd9/Nh+fuv7rZJCEzPubHUvoZL6 utiTItzc9m9yHk0dh5PbB26vqWpEQan0HttwilfEz1M/VOX4+I5kcrq8Ls55e6WUVh c2+38AN+db3lFXHIIB4IY4jZVtwaRhPJPw9KOVvnrXelKcwBWnOWtyiiBIj1hdx+aM n7ljNSQ1AnaLKBYfP1qPX1xYA7ifu1EsHmW4HZ/yJpm3iSycPohQjxpBdu/6GOgQ5m bJaivbMvG2Hh4kJg1UvfJqGudncxLBjI1Op6Qppl9Ok47WUVbgdooczlhBWQGNsSke l5F0NsWgA+96g== 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.98.2) (envelope-from ) id 1wgdha-00000001nC5-16mh; Mon, 06 Jul 2026 07:25:14 +0000 Date: Mon, 06 Jul 2026 08:25:13 +0100 Message-ID: <86o6gkpokm.wl-maz@kernel.org> From: Marc Zyngier To: Tangnianyao Cc: Wei-Lin Chang , , , , , , , , , , , "guoyang (C)" , "huanglingyan (A)" , "Wangzhou (B)" Subject: Re: Question about the "TLBs and I-cache are private to each vCPU" guarantee with VTTBR_EL2.CnP In-Reply-To: <292b5734-9005-6db0-da08-3da04628e620@huawei.com> References: <292b5734-9005-6db0-da08-3da04628e620@huawei.com> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tangnianyao@huawei.com, weilin.chang@arm.com, oupton@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, guoyang2@huawei.com, huanglingyan2@huawei.com, wangzhou1@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 06 Jul 2026 04:30:30 +0100, Tangnianyao wrote: >=20 >=20 >=20 > On 7/6/2026 1:28, Wei-Lin Chang wrote: > > Hi, > > > > Let me try to answer this: > > > > On Sat, Jul 04, 2026 at 03:45:56PM +0800, Tangnianyao wrote: > >> Hi, all > >> > >> I'm trying to understand the TLB and I-cache invalidation in > >> `kvm_arch_vcpu_load()` that is intended to "guarantee that both TLBs a= nd > >> I-cache are private to each vCPU". > >> > >> As I understand it, when `VTTBR_EL2.CnP =3D=3D 1`, `__kvm_flush_cpu_co= ntext()` > >> only performs a local TLB and I-cache invalidation, which does not seem > >> sufficient to guarantee that property. > >> > >> In fact, even if the invalidation were extended to the Inner Shareable > >> domain, it still seems difficult to guarantee =E2=80=9CTLBs and I-cach= e are > >> private to each vCPU=E2=80=9D, when `VTTBR_EL2.CnP =3D=3D 1`, as long = as multiple > >> vCPUs from the same VM may be running concurrently on different PEs. > > I think you have missed that when 2 stages are involved, both stages > > have to set CnP =3D=3D 1 in order to share TLB entries (Arm ARM R_ZVRZW= ). > > So if TLB entry sharing happens, the guest kernel must have allowed it > > in the first place (by setting TTBR0/1_EL1.CnP =3D=3D 1), hence acciden= tal > > sharing that you are worried about won't happen. > > > > __kvm_flush_cpu_context() is solving problems that occur when multiple > > vCPUs of a VM are multiplexed on a single physical CPU. >=20 > Thanks for you answer. >=20 > If guest kernel allow TLB shared across CPUs by setting TTBR0/1_EL1.CnP = =3D=3D 1, > does kvm still need to guarantee that TLBs are private to each vCPU? Yes, because there is nothing that describes which physical CPUs actually share TLBs. So the only possible course of action is to ignore what the guest says and fallback to something that is safe. > > >> So I have two questions: > >> > >> 1. What is the rationale behind the comment that "guarantee that both = TLBs > >> and I-cache are private to each vCPU"? > > I assume you are asking why keeping both TLBs and I-cache private per > > each vCPU is required. The fundamental answer is that each physical CPU > > is expected to have its own TLB and I-cache, so we must uphold that > > property for vCPUs as well. vCPUs can be scheduled on the same physical > > CPU, and use the same physical TLB/I-cache, obviously, so extra > > invalidations need to be done. > Let's assume that both Stage-1 CnP and Stage-2 CnP are enabled. >=20 > As I understand it, the architecture permits TLB to be shared by multiple > PEs within an Inner Shareable domain. Right? >=20 > If an implementation allows TLB entries to be shared in this way, it seems > that the current invalidation performed by kvm would no longer be suffici= ent > to guarantee that TLBs are private to each vCPU. Care to explain why? The core assumption is that a TLBI take effect on all the PEs the TLB is shared with. If this doesn't work, then CnP is unusable, because it is then impossible to guarantee that a translation will be refetched (you could always hit in another PEs TLBs). Such an implementation would be terminally broken. M. --=20 Without deviation from the norm, progress is not possible.