Re: [PATCH 1/2] KVM: arm64: Hide FEAT_LS64_ACCDATA from guests

[Marc Zyngier <maz@kernel.org>]

On Fri, 23 Oct 2026 10:08:11 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> Hi Marc,
> 
> On Fri, 23 Oct 2026 09:31:32 +0100, Marc Zyngier <maz@kernel.org> wrote:
> [...]
> > Why settle for the least capable option? Context switching ACCDATA_EL1
> > is easy enough, can be gated on guest features, and avoid the
> > userspace horror story.
> >
> > I'd rather see that.
> 
> Context switching it means accessing ACCDATA_EL1 at EL2, which traps
> to EL3 unless SCR_EL3.ADEn is set. booting.rst doesn't require ADEn
> today, and TF-A only sets it when built with ENABLE_FEAT_LS64_ACCDATA,
> which defaults to off.

I couldn't care less.

booting.rst is not authoritative and has absolutely no value when it
comes to trap bits. Firmware could perfectly enable a feature on trap
instead of catching fire.  Additionally, shipping firmware that
doesn't support features that the CPU advertises is a bug, and I want
to see these systems burn.

> On such a host, KVM traps to EL3 the first time
> it switches ACCDATA_EL1 for a VM, and every VM has LS64_ACCDATA by
> default. The cap leaves the register alone, and the fine-grained trap
> takes priority over ADEn, so it works whatever ADEn is set to.
> 
> Should we keep the cap as the fix for stable, and post ACCDATA support
> on top? If you agree, I'd rebase your patches 3, 4 and 8 from [1], add
> a booting.rst requirement for ADEn and EnAS0, and lift the cap and the
> compat.

No, I want this fixed by enabling ACCDATA support by default, which is
what we have *already* promised to userspace, and see the fireworks.
You can add an arm64.nols64 kernel option if you want, which is
consistent with what we do for CNTPOFF, NV3, and other extensions that
depend on FW enabling them.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.