On Thu, Jan 08, 2026 at 02:09:34PM +0000, Fuad Tabba wrote:

On Thu, 8 Jan 2026 at 11:54, Mark Brown [off-list ref] wrote:

quoted

On Wed, Jan 07, 2026 at 07:25:04PM +0000, Fuad Tabba wrote:

quoted

On Tue, 23 Dec 2025 at 01:21, Mark Brown [off-list ref] wrote:

quoted

quoted

Should we also preserve the remaining old bits from SMCR_EL1, i.e.,
copy over the bits that aren't
SMCR_ELx_LEN_MASK|SMCR_ELx_FA64|SMCR_ELx_EZT0? For now they are RES0,
but that could change.

quoted

My thinking here is that any new bits are almost certainly going to need
explicit support (like with the addition of ZT0) and that copying them
forward without understanding is more likely to lead to a bug like
exposing state we didn't mean to than clearing them will.

I understand the 'secure by default' intent for enable bits, but I'm
concerned that this implementation changes the current behavior of the
host kernel, which isn't mentioned in the commit message. Previously,
both the feature enablement code (cpu_enable_fa64) and the vector
length setting code (sme_set_vq/write_vl) performed a RMW, preserving
existing bits in SMCR_EL1. This new macro zeroes out any bits not
explicitly tracked here.

The behaviour is unchanged since we're always choosing the same value in
the end, it's just a question of rearranging when do it which is the
explicit goal of the change.  There won't be a change in behaviour until
later on in the series when we start potentially choosing other settings
for KVM guests.

In terms of copying them over, if they were set from the beginning,
doesn't that mean that that explicit support was already added?

That's a bit circular, with the new interface if someone updates the
kernel to set some new bits they're going to have to update this code as
part of that.  A part of the goal here is to make it harder to make a
mistake with remembering what needs to be updatd when.