On 16/05/18 12:01, Russell King wrote: > __v7_cr7mp_proc_info: > .long 0x410fc170 > .long 0xff0ffff0 > - __v7_proc __v7_cr7mp_proc_info, __v7_cr7mp_setup > + __v7_proc __v7_cr7mp_proc_info, __v7_cr7mp_setup, proc_fns = HARDENED_BPIALL_PROCESSOR_FUNCTIONS > .size __v7_cr7mp_proc_info, . - __v7_cr7mp_proc_info > > /* > @@ -649,7 +700,7 @@ ENDPROC(__v7_setup) > __v7_cr8mp_proc_info: > .long 0x410fc180 > .long 0xff0ffff0 > - __v7_proc __v7_cr8mp_proc_info, __v7_cr8mp_setup > + __v7_proc __v7_cr8mp_proc_info, __v7_cr8mp_setup, proc_fns = HARDENED_BPIALL_PROCESSOR_FUNCTIONS > .size __v7_cr8mp_proc_info, . - __v7_cr8mp_proc_info For R-class cores, the mitigation doesn't make much sense since we do not enforce user/kernel isolation anyway. I believe the same also applies to A-class cores built with !MMU, so you might want to guard CPU_SPECTRE with MMU in PATCH 05/14. Cheers Vladimir _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
