On Thu, 8 Jan 2026 at 15:57, Mark Brown <[email protected]> wrote: > > On Thu, Jan 08, 2026 at 02:09:34PM +0000, Fuad Tabba wrote: > > On Thu, 8 Jan 2026 at 11:54, Mark Brown <[email protected]> wrote: > > > On Wed, Jan 07, 2026 at 07:25:04PM +0000, Fuad Tabba wrote: > > > > On Tue, 23 Dec 2025 at 01:21, Mark Brown <[email protected]> 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.
Fair point. If the intent is to enforce a strict known state and force updates here when new features are added, that makes sense. Would it be worth adding a comment above the macro noting this difference from sve_cond_update_zcr_vq()? Something along the lines of 'Intentionally overwrites to ensure strict control of enable bits', to save future readers from getting confused... Thanks, /fuad
