From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH v1 4/5] arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled
Date: Thu, 27 Nov 2025 14:17:39 +0000 [thread overview]
Message-ID: <86345zr24c.wl-maz@kernel.org> (raw)
In-Reply-To: <20251127122210.4111702-5-tabba@google.com>
On Thu, 27 Nov 2025 12:22:09 +0000,
Fuad Tabba <tabba@google.com> wrote:
>
> When MTE hardware is present but disabled via software (arm64.nomte or
> CONFIG_ARM64_MTE=n), HCR_EL2.ATA is cleared to prevent use of MTE
> instructions. However, this alone doesn't fully emulate hardware that
> lacks MTE support.
>
> With HCR_EL2.ATA cleared, accesses to certain MTE system registers trap
> to EL2 with exception class ESR_ELx_EC_SYS64. To faithfully emulate
> hardware without MTE (where such accesses would cause an Undefined
> Instruction exception), inject UNDEF into the host.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 44 ++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 29430c031095..f542e4c17156 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -686,6 +686,46 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> kvm_skip_host_instr();
> }
>
> +static void inject_undef64(void)
> +{
> + unsigned long sctlr, vbar, old, new;
> + u64 offset, esr;
> +
> + vbar = read_sysreg_el1(SYS_VBAR);
> + sctlr = read_sysreg_el1(SYS_SCTLR);
> + old = read_sysreg_el2(SYS_SPSR);
> + new = get_except64_cpsr(old, system_supports_mte(), sctlr, PSR_MODE_EL1h);
> + offset = get_except64_offset(old, PSR_MODE_EL1h, except_type_sync);
> + esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
> +
> + write_sysreg_el1(esr, SYS_ESR);
> + write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> + write_sysreg_el1(old, SYS_SPSR);
> + write_sysreg_el2(vbar + offset, SYS_ELR);
> + write_sysreg_el2(new, SYS_SPSR);
> +}
> +
> +static bool handle_host_mte(u64 esr)
> +{
> + /* If we're here for any reason other than MTE, then it's a bug. */
> +
> + if (read_sysreg(HCR_EL2) & HCR_ATA)
> + return false;
> +
> + switch (esr_sys64_to_sysreg(esr)) {
> + case SYS_RGSR_EL1:
> + case SYS_GCR_EL1:
> + case SYS_TFSR_EL1:
> + case SYS_TFSRE0_EL1:
How about other things, such as DC GVA? Don't you need to trap and
UNDEF it (which has the side effect of also trapping DC ZVA)?
Same question for all the DC {C,I,CI}GVA{C,P} instructions.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-11-27 14:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 12:22 [PATCH v1 0/5] KVM: arm64: Enforce MTE disablement at EL2 Fuad Tabba
2025-11-27 12:22 ` [PATCH v1 1/5] arm64: Remove dead code resetting HCR_EL2 for pKVM Fuad Tabba
2025-11-27 12:22 ` [PATCH v1 2/5] arm64: Clear HCR_EL2.ATA when MTE is not supported or disabled Fuad Tabba
2025-11-27 12:22 ` [PATCH v1 3/5] KVM: arm64: Refactor enter_exception64() Fuad Tabba
2025-11-27 12:22 ` [PATCH v1 4/5] arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled Fuad Tabba
2025-11-27 14:17 ` Marc Zyngier [this message]
2025-11-27 14:41 ` Fuad Tabba
2025-11-28 8:43 ` Marc Zyngier
2025-11-28 8:53 ` Fuad Tabba
2025-11-28 12:10 ` Will Deacon
2025-11-27 12:22 ` [PATCH v1 5/5] KVM: arm64: Use kvm_has_mte() in pKVM trap initialization Fuad Tabba
2025-12-02 22:43 ` [PATCH v1 0/5] KVM: arm64: Enforce MTE disablement at EL2 Oliver Upton
2025-12-05 17:00 ` Will Deacon
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=86345zr24c.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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;
as well as URLs for NNTP newsgroup(s).