arch/arc/include/asm/mmu_context.h
Source file repositories/reference/linux-study-clean/arch/arc/include/asm/mmu_context.h
File Facts
- System
- Linux kernel
- Corpus path
arch/arc/include/asm/mmu_context.h- Extension
.h- Size
- 5567 bytes
- Lines
- 175
- Domain
- Architecture Layer
- Bucket
- arch/arc
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/sched/mm.hasm/tlb.hasm-generic/mm_hooks.hasm-generic/mmu_context.h
Detected Declarations
function get_new_mmu_contextfunction init_new_contextfunction destroy_contextfunction switch_mm
Annotated Snippet
#ifndef _ASM_ARC_MMU_CONTEXT_H
#define _ASM_ARC_MMU_CONTEXT_H
#include <linux/sched/mm.h>
#include <asm/tlb.h>
#include <asm-generic/mm_hooks.h>
/* ARC ASID Management
*
* MMU tags TLBs with an 8-bit ASID, avoiding need to flush the TLB on
* context-switch.
*
* ASID is managed per cpu, so task threads across CPUs can have different
* ASID. Global ASID management is needed if hardware supports TLB shootdown
* and/or shared TLB across cores, which ARC doesn't.
*
* Each task is assigned unique ASID, with a simple round-robin allocator
* tracked in @asid_cpu. When 8-bit value rolls over,a new cycle is started
* over from 0, and TLB is flushed
*
* A new allocation cycle, post rollover, could potentially reassign an ASID
* to a different task. Thus the rule is to refresh the ASID in a new cycle.
* The 32 bit @asid_cpu (and mm->asid) have 8 bits MMU PID and rest 24 bits
* serve as cycle/generation indicator and natural 32 bit unsigned math
* automagically increments the generation when lower 8 bits rollover.
*/
#define MM_CTXT_ASID_MASK 0x000000ff /* MMU PID reg :8 bit PID */
#define MM_CTXT_CYCLE_MASK (~MM_CTXT_ASID_MASK)
#define MM_CTXT_FIRST_CYCLE (MM_CTXT_ASID_MASK + 1)
#define MM_CTXT_NO_ASID 0UL
#define asid_mm(mm, cpu) mm->context.asid[cpu]
#define hw_pid(mm, cpu) (asid_mm(mm, cpu) & MM_CTXT_ASID_MASK)
DECLARE_PER_CPU(unsigned int, asid_cache);
#define asid_cpu(cpu) per_cpu(asid_cache, cpu)
/*
* Get a new ASID if task doesn't have a valid one (unalloc or from prev cycle)
* Also set the MMU PID register to existing/updated ASID
*/
static inline void get_new_mmu_context(struct mm_struct *mm)
{
const unsigned int cpu = smp_processor_id();
unsigned long flags;
local_irq_save(flags);
/*
* Move to new ASID if it was not from current alloc-cycle/generation.
* This is done by ensuring that the generation bits in both mm->ASID
* and cpu's ASID counter are exactly same.
*
* Note: Callers needing new ASID unconditionally, independent of
* generation, e.g. local_flush_tlb_mm() for forking parent,
* first need to destroy the context, setting it to invalid
* value.
*/
if (!((asid_mm(mm, cpu) ^ asid_cpu(cpu)) & MM_CTXT_CYCLE_MASK))
goto set_hw;
/* move to new ASID and handle rollover */
if (unlikely(!(++asid_cpu(cpu) & MM_CTXT_ASID_MASK))) {
local_flush_tlb_all();
/*
* Above check for rollover of 8 bit ASID in 32 bit container.
* If the container itself wrapped around, set it to a non zero
* "generation" to distinguish from no context
*/
if (!asid_cpu(cpu))
asid_cpu(cpu) = MM_CTXT_FIRST_CYCLE;
}
/* Assign new ASID to tsk */
asid_mm(mm, cpu) = asid_cpu(cpu);
set_hw:
mmu_setup_asid(mm, hw_pid(mm, cpu));
local_irq_restore(flags);
}
/*
* Initialize the context related info for a new mm_struct
* instance.
Annotation
- Immediate include surface: `linux/sched/mm.h`, `asm/tlb.h`, `asm-generic/mm_hooks.h`, `asm-generic/mmu_context.h`.
- Detected declarations: `function get_new_mmu_context`, `function init_new_context`, `function destroy_context`, `function switch_mm`.
- Atlas domain: Architecture Layer / arch/arc.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.