On 10/13/2026 11:54 AM, H. Peter Anvin wrote: > On 2026-10-08 19:00, Sohil Mehta wrote: >> >> Note, the CPUID bit does not reflect whether the kernel enabled LASS; >> only the cpuinfo flag does. But parsing cpuinfo is cumbersome, and the >> kernel enables LASS whenever the CPU supports it unless the command line >> opts out (vsyscall=emulate or clearcpuid=lass). To keep it simple, rely >> on the CPUID bit and accept a failure in these unusual cases. >> > Cumbersome, really? >
I had it in v1 of this patch. It seemed excessive to do specifically for LASS: https://lore.kernel.org/lkml/[email protected]/ As LASS is always enabled by the kernel except for the really odd cases the trade-off seems practical to me. > Here is a set of parsing functions -- tested, even! -- that you can make > available as library routines. Integrating them into the selftests build > framework has been left as an exercise for the reader ;-) > I agree, adding them as generic selftest helpers may be useful. But, /proc/cpuinfo has been unreliable in general. It is currently buggy for some features with Kconfig options. See: https://lore.kernel.org/lkml/f6f113b46199d996c4f81fc89858c2f484256418.1774623092.git.m.wieczorret...@pm.me/ Also, (I think) we have been generally discouraging folks to add more bits there. So, I don't know if creating these library routines is useful right now. IIUC, Boris said that the CPUID rework would make some of cpuinfo stuff moot. https://lore.kernel.org/lkml/20260331140216.GDacvT6IPW1gf003z-@fat_crate.local/ Thoughts?
