[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86h6mmn1sb.wl-maz@kernel.org>
Date: Thu, 19 Oct 2023 15:07:48 +0100
From: Marc Zyngier <maz@...nel.org>
To: Miguel Luis <miguel.luis@...cle.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Jing Zhang <jingzhangos@...gle.com>,
Eric Auger <eric.auger@...hat.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>
Subject: Re: [PATCH v4 2/3] arm64: Add missing _EL2 encodings
On Thu, 19 Oct 2023 14:23:09 +0100,
Miguel Luis <miguel.luis@...cle.com> wrote:
>
> Hi Marc,
>
> > On 19 Oct 2023, at 11:39, Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Mon, 16 Oct 2023 12:17:41 +0100,
> > Miguel Luis <miguel.luis@...cle.com> wrote:
> >>
> >> Some _EL2 encodings are missing. Add them.
> >>
> >> Signed-off-by: Miguel Luis <miguel.luis@...cle.com>
> >> ---
> >> arch/arm64/include/asm/sysreg.h | 39 +++++++++++++++++++++++++++++++++
> >> 1 file changed, 39 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> >> index ba5db50effec..8653fb67a339 100644
> >> --- a/arch/arm64/include/asm/sysreg.h
> >> +++ b/arch/arm64/include/asm/sysreg.h
> >
> > [...]
> >
> >> +#define SYS_SDER32_EL2 sys_reg(3, 4, 1, 3, 1)
> >
> > [...]
> >
> >> +#define SYS_VSTTBR_EL2 sys_reg(3, 4, 2, 6, 0)
> >> +#define SYS_VSTCR_EL2 sys_reg(3, 4, 2, 6, 2)
> >
> > [...]
> >
> >> +#define SYS_CNTHVS_TVAL_EL2 sys_reg(3, 4, 14, 4, 0)
> >> +#define SYS_CNTHVS_CTL_EL2 sys_reg(3, 4, 14, 4, 1)
> >> +#define SYS_CNTHVS_CVAL_EL2 sys_reg(3, 4, 14, 4, 2)
> >> +#define SYS_CNTHPS_TVAL_EL2 sys_reg(3, 4, 14, 5, 0)
> >> +#define SYS_CNTHPS_CTL_EL2 sys_reg(3, 4, 14, 5, 1)
> >> +#define SYS_CNTHPS_CVAL_EL2 sys_reg(3, 4, 14, 5, 2)
> >
> > While the secure definitions seem correct, what is the rationale
> > behind their presence here? They cannot be trapped from non-secure,
> > and the pseudocode is pretty explicit:
> >
> > if !IsCurrentSecurityState(SS_Secure) then
> > UNDEFINED;
> >
> > Given that, they cannot be trapped, handled or accessed from a KVM
> > guest, as Linux on arm64 *always* runs non-secure.
> >
>
> Thank you for clarifying.
>
> Those definitions were needed for the refinement on patch 3 which clearly
> didn’t considered that statement beforehand.
>
> Yet, should we keep them here so they could be used?
But that's the whole point: they *cannot* be used. You can't use a
secure system register in non-secure, and we *always* run in
non-secure, no ifs no buts.
If a guest ever uses one of those, it will get an UNDEF exception
directly, without any SW intervention, because that's just illegal.
KVM will never see it.
As far as Linux is concerned, this is purely dead code.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists