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.
signature.asc
Description: PGP signature
