[PATCH 6/6] powerpc/64s/radix: introduce options to disable use of the tlbie instruction

[Nicholas Piggin]

Alistair Popple's on September 3, 2019 10:32 am:
> Nick,
> 
> On Tuesday, 3 September 2019 1:29:31 AM AEST Nicholas Piggin wrote:
>> Introduce two options to control the use of the tlbie instruction. A
>> boot time option which completely disables the kernel using the
>> instruction, this is currently incompatible with HASH MMU, KVM, and
>> coherent accelerators.
> 
> Some accelerators (eg. cxl, ocxl, npu) call mm_context_add_copro() to force 
> global TLB invalidations:
> 
> static inline void mm_context_add_copro(struct mm_struct *mm)
> {
>         /*
>          * If any copro is in use, increment the active CPU count
>          * in order to force TLB invalidations to be global as to
>          * propagate to the Nest MMU.
>          */
>         if (atomic_inc_return(&mm->context.copros) == 1)
>                 inc_mm_active_cpus(mm);
> }
> 
> Admittedly I haven't dug into all the details of this patch but it sounds like 
> it might break the above if TLBIE is disabled. Do you think we should add a 
> WARN_ON if mm_context_add_copro() is called with TLBIE disabled? Or perhaps 
> even force TLBIE to be re-enabled if it is called with it disabled?

The patch has two flags, "enabled" and "capable". If capable is false
then it prevents cxl, oxcl, and KVM from loading. I think NPU is gone
from the tree now. Hash MMU won't work either, but for now you can't
mark !capable with hash.

If enabled is false but capable is true, then it avoids tlbie for
flushing the CPU translations, but will also use it to flush nMMU
coprocessors (and KVM for partition scope, but hopefully that can
be made to work with tlbiel as well).

So this should be fine. Could put a BUG in there if !tlbie_capable,
because we can't continue -- idea is that tlbie could be broken or
not implemented or we want to test without ever using it.

Thanks,
Nick