From: Marc Zyngier <maz@kernel.org>
To: Tangnianyao <tangnianyao@huawei.com>
Cc: Wei-Lin Chang <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>,
"guoyang (C)" <guoyang2@huawei.com>,
"huanglingyan (A)" <huanglingyan2@huawei.com>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: Question about the "TLBs and I-cache are private to each vCPU" guarantee with VTTBR_EL2.CnP
Date: Mon, 06 Jul 2026 08:25:13 +0100 [thread overview]
Message-ID: <86o6gkpokm.wl-maz@kernel.org> (raw)
In-Reply-To: <292b5734-9005-6db0-da08-3da04628e620@huawei.com>
On Mon, 06 Jul 2026 04:30:30 +0100,
Tangnianyao <tangnianyao@huawei.com> wrote:
>
>
>
> 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 and
> >> I-cache are private to each vCPU".
> >>
> >> As I understand it, when `VTTBR_EL2.CnP == 1`, `__kvm_flush_cpu_context()`
> >> 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 “TLBs and I-cache are
> >> private to each vCPU”, when `VTTBR_EL2.CnP == 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 == 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 == 1), hence accidental
> > 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.
>
> Thanks for you answer.
>
> If guest kernel allow TLB shared across CPUs by setting TTBR0/1_EL1.CnP == 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.
>
> As I understand it, the architecture permits TLB to be shared by multiple
> PEs within an Inner Shareable domain. Right?
>
> 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 sufficient
> 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.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-07-06 7:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 7:45 Question about the "TLBs and I-cache are private to each vCPU" guarantee with VTTBR_EL2.CnP Tangnianyao
2026-07-05 17:28 ` Wei-Lin Chang
2026-07-06 3:30 ` Tangnianyao
2026-07-06 7:25 ` Marc Zyngier [this message]
2026-07-06 8:25 ` Tangnianyao
2026-07-06 8:44 ` Marc Zyngier
2026-07-06 14:15 ` Tangnianyao
2026-07-06 15:18 ` Will Deacon
2026-07-06 15:33 ` Mark Rutland
2026-07-07 2:41 ` Tangnianyao
2026-07-07 6:36 ` Oliver Upton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o6gkpokm.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=guoyang2@huawei.com \
--cc=huanglingyan2@huawei.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tangnianyao@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=weilin.chang@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox