From: Marc Zyngier <maz@kernel.org>
To: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Shuah Khan <shuah@kernel.org>, Oliver Upton <oupton@kernel.org>,
Fuad Tabba <fuad.tabba@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-kselftest@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v3] KVM: arm64: selftests: Test VNCR translation invalidation
Date: Mon, 26 Oct 2026 08:30:07 +0000 [thread overview]
Message-ID: <861p9czwxc.wl-maz@kernel.org> (raw)
In-Reply-To: <20261026-b4-vncr-mapping-test-v3-1-7c094a00d46e@fujitsu.com>
On Mon, 26 Oct 2026 03:10:10 +0000,
Itaru Kitayama <itaru.kitayama@fujitsu.com> wrote:
>
> Add a standalone KVM selftest that checks VNCR accesses after L1
> updates its stage-1 mapping and issues a TLBI. This guards against
> stale VNCR translations, as KVM caches L1's translation of
> VNCR_EL2 and must drop it when L1 invalidates the mapping in
> kvm_handle_s1e2_tlbi().
>
> Keep VNCR_EL2 unchanged while remapping its backing page A to B then
> again to A. At each step, L2 reads and writes TPIDR_EL2, and L1
> verifies that the accesses reach the selected page while leaving the
> other page unchanged.
If you were tracking cross vcpu invalidation and exercising all the
architecture corner cases (such as permission changes and co), that
would be helpful.
But as it is, it doesn't help much as a validation tool. Its scope is
way too narrow.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-10-26 8:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 3:10 [PATCH v3] KVM: arm64: selftests: Test VNCR translation invalidation Itaru Kitayama
2026-10-26 8:21 ` Fuad Tabba
2026-10-26 8:30 ` Marc Zyngier [this message]
2026-10-26 21:43 ` Itaru Kitayama
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=861p9czwxc.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=itaru.kitayama@fujitsu.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=seiden@linux.ibm.com \
--cc=shuah@kernel.org \
--cc=suzuki.poulose@arm.com \
--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