[RFC 3/8] ARM64: Base TLB functions

[Christoph Lameter (Ampere)]

On Mon, 4 Mar 2024, Catalin Marinas wrote:

> I don't think any of these patches made it to the list for some reason,
> only the cover letter. I'll add some general comments below in case you
> plan to repost.

Correct. I believe I have fixed the isue but did not get around to repost 
the patchset.

>
> On Wed, Dec 06, 2023 at 07:57:06PM -0800, Christoph Lameter wrote:
>> Add a series of TLB function that allow TLB flushing in a variety of
>> ways depending on the mode encoded in enum tlb_state:
>>
>> TLB_BROADCOAST	-> Use single TLBI propagated to all units via the mesh
>> TLB_LOCAL	-> Use TLBI that only perform local flushes
>> TLB_IPI		-> Use TLBIs that perform local flushes on multiple cpus
>> TLB_NONE	-> Suppress TLBI because there are no users of the address space
>
> TLB_IPI - I really don't want this on arm64, irrespective of the
> performance improvement on specific hardware. IPIs need additional care
> to avoid deadlocking, e.g. don't do a TLBI with interrupts disabled. I'd
> rather not have to care about this.

These are commonly used on other platforms in these paths. So I assumed it 
would be safe.

> TLB_LOCAL and TLB_NONE - these are potentially useful _but_ they don't
> take the SMMU with SVA into account (another potential issue below). The
> mm_cpumask() does not track other non-CPU contexts but they do need the
> broadcast TLBI.

Hmm....I assume there is no way to determine if a TLB entry is in use by 
non-cpu contexts? There are MMU notifiers typically used for devices that 
require context outside of a cpu and that also flush the information. 
There are already callbacks in the ARM64 tlb flushing code to support MMU 
notifications.

>> +static enum tlb_state tlbstat(struct cpumask *mask)
>> +{
>> +	unsigned int weight = cpumask_weight(mask);
>> +	bool present = cpumask_test_cpu(smp_processor_id(), mask);
>
> Is this guaranteed to be called in a non-preemptible context? My biggest
> concern with the cpumask tracking is that the thread is migrated in the
> middle of a TLB flush and it would wrongly assume that only a local TLBI
> is needed. On arm64 we don't flush the TLBs on context switch. I don't
> think we can solve this without additional locking around mm_cpumask()
> or at least preemption disabling.

This would mean that the scheduler moves the process while the kernel 
executes a tlb flush operation.

TLB operations are related to page table modifications and those require 
to take a write lock on the mmap lock. This would prevent issues here.