Messages in this thread | | | Date | Wed, 7 Feb 2024 13:51:42 +0000 | From | Dave Martin <> | Subject | Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset |
| |
On Wed, Feb 07, 2024 at 01:09:51PM +0000, Mark Brown wrote: > On Wed, Feb 07, 2024 at 12:23:56PM +0000, Dave Martin wrote: > > On Mon, Feb 05, 2024 at 05:41:47PM +0000, Mark Brown wrote: > > > On Mon, Feb 05, 2024 at 05:11:59PM +0000, Dave Martin wrote: > > > > > If the kernel is now juggling two #defines for the maximum vector size, > > > > this feels like it may seed bitrot... > > > > Ideally we'd just not have the existing define externally but it's there > > > and it's been used. > > > To clarify, is this intended as a temporary band-aid against silly > > behaviour while a cleaner solution is found, or a permanent limitation? > > Ideally we'd just make everything dynamic, other than the regset issue > and the bitmasks used for VL enumeration we're there already. Making > the bitmasks dynamically sized is more painful but are also doing > enumeration that userspace doesn't need to do.
For the bitmasks, we'd be saving (512 - 16) / 8 = 62 bytes for each of SVE and SME (I think).
The tradeoff really didn't seem worth it...
> > > We'd need to change various things if the architectural max VL actually > > grew, so no forward-portability is lost immediately if the kernel > > adopts 16 internally, but I'm still a little concerned that people may > > poke about in the kernel code as a reference and this will muddy the > > waters regarding how to do the right thing in userspace (I know people > > shouldn't, but...) > > I think if we fix the ptrace regset issue we're doing a good enough job > of just using fully dynamic sizing with no limits other than what's been > enumerated there. We could possibly deal with the enumberation code by > changing it to use ZCR/SMCR_ELx_LEN_ based defines so that it's > obviously coming from what we can possibly write to the register but > it's a bit less clear how to do that neatly.
OK, but we still seem to have two competing approaches: clamp SVE_VQ_MAX for kernel internal purposes, or restore the dynamic sizing of NT_ARM_SVE based on the new regset core behaviour.
Are you saying we should or both, or otherwise which one?
Cheers ---Dave
| |