Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks

[Maciej W. Rozycki]

On Wed, 26 Oct 2022, Arnd Bergmann wrote:

> >> In fact, I don't understand how current kernels work on an i486 at
> >> all, since it looks like
> >> 
> >>   exit_to_user_mode_prepare ->
> >>     arch_exit_to_user_mode_prepare
> >> 
> >> ends up having an unconditional 'rdtsc' instruction in it.
> >> >
> >  The fix here is obviously and trivially:
> >
> > 	select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET if !M486SX && !M486
> 
> I think that would be "if X86_TSC", otherwise you still include the
> TSC-less 586-class (5x86, 6x86, Elan, Winchip C6, MediaGX, ...)

 Right, I tend to forget about these more exotic chips from the 1990s era.  
I'll run some verification and come up with the actual fix in the next 
several days.

> > So what's the actual burden from keeping this support around?  Would my 
> > proposal to emulate CMPXCHG8B (and possibly RDTSC) in #UD handler help?
> 
> That sounds worse to me than the current use of runtime alternatives
> for picking between cmpxchg8b_emu and the native instruction.

 Why is that so?  Because of the trap-and-emulate technique?  It's been 
around since forever and specified in some processor ISAs even, where some 
machine instructions are explicitly allowed to be omitted from actual 
hardware and delegated to OS emulation without making affected hardware 
non-compliant.  VAX had it back from 1970s and RISC-V has it now.  We've 
been using it to retrofit operations ourselves, though maybe not with the 
x86 arch.

 Or is it because of the complex address decoding x86 requires?  Well, I 
have actually realised we do have it already, in the x87 CR0.EM emulator.  
While IEEE-754 exceptions can make use of the address of the operand 
recorded in the FPU environment full emulation requires decoding by hand.

> For arm32, we have a combination of two other approaches:
> 
> - On the oldest processors that never had SMP support (ARMv5 and
>   earlier), it is not possible to enable support for SMP at all.
>   Using a Kconfig 'depends on X86_CMPXCHG64' for CONFIG_SMP would
>   still allow building 486 kernels, but completely avoid the problem
>   of trying to make the same kernel work on later SMP machines.

 That would be fine with me of course.

> - For the special case of early ARMv6 hardware that has 32-bit
>   atomics but not 64-bit ones, the kernel just falls back to
>   CONFIG_GENERIC_ATOMIC64 and no cmpxchg64(). The same should work
>   for an i486+SMP kernel. It's obviously slower, but most users
>   can trivially avoid this by either running an i686 SMP kernel
>   or an i486 UP kernel.

 You meant an M586TSC+ SMP kernel presumably (I have such a machine), but 
otherwise I'd be fine with such an approach too.

 So it looks to me like we have at least three options to keep 486 alive,
two of which seem fairly straightforward to deploy and maintain long-term.  
I like your last proposal the most, FWIW.  Do we have a consensus here?

  Maciej