On Thu, Jan 08, 2026 at 02:09:34PM +0000, Fuad Tabba wrote:
On Thu, 8 Jan 2026 at 11:54, Mark Brown broonie@kernel.org wrote:
On Wed, Jan 07, 2026 at 07:25:04PM +0000, Fuad Tabba wrote:
On Tue, 23 Dec 2025 at 01:21, Mark Brown broonie@kernel.org wrote:
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.
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.