arch/powerpc/include/asm/exception-64e.h
Source file repositories/reference/linux-study-clean/arch/powerpc/include/asm/exception-64e.h
File Facts
- System
- Linux kernel
- Corpus path
arch/powerpc/include/asm/exception-64e.h- Extension
.h- Size
- 5858 bytes
- Lines
- 173
- Domain
- Architecture Layer
- Bucket
- arch/powerpc
- 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.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef _ASM_POWERPC_EXCEPTION_64E_H
#define _ASM_POWERPC_EXCEPTION_64E_H
/*
* SPRGs usage an other considerations...
*
* Since TLB miss and other standard exceptions can be interrupted by
* critical exceptions which can themselves be interrupted by machine
* checks, and since the two later can themselves cause a TLB miss when
* hitting the linear mapping for the kernel stacks, we need to be a bit
* creative on how we use SPRGs.
*
* The base idea is that we have one SRPG reserved for critical and one
* for machine check interrupts. Those are used to save a GPR that can
* then be used to get the PACA, and store as much context as we need
* to save in there. That includes saving the SPRGs used by the TLB miss
* handler for linear mapping misses and the associated SRR0/1 due to
* the above re-entrancy issue.
*
* So here's the current usage pattern. It's done regardless of which
* SPRGs are user-readable though, thus we might have to change some of
* this later. In order to do that more easily, we use special constants
* for naming them
*
* WARNING: Some of these SPRGs are user readable. We need to do something
* about it as some point by making sure they can't be used to leak kernel
* critical data
*/
#define PACA_EXGDBELL PACA_EXGEN
/* We are out of SPRGs so we save some things in the PACA. The normal
* exception frame is smaller than the CRIT or MC one though
*/
#define EX_R1 (0 * 8)
#define EX_CR (1 * 8)
#define EX_R10 (2 * 8)
#define EX_R11 (3 * 8)
#define EX_R14 (4 * 8)
#define EX_R15 (5 * 8)
/*
* The TLB miss exception uses different slots.
*
* The bolted variant uses only the first six fields,
* which in combination with pgd and kernel_pgd fits in
* one 64-byte cache line.
*/
#define EX_TLB_R10 ( 0 * 8)
#define EX_TLB_R11 ( 1 * 8)
#define EX_TLB_R14 ( 2 * 8)
#define EX_TLB_R15 ( 3 * 8)
#define EX_TLB_R16 ( 4 * 8)
#define EX_TLB_CR ( 5 * 8)
#define EX_TLB_R12 ( 6 * 8)
#define EX_TLB_R13 ( 7 * 8)
#define EX_TLB_DEAR ( 8 * 8) /* Level 0 and 2 only */
#define EX_TLB_ESR ( 9 * 8) /* Level 0 and 2 only */
#define EX_TLB_SRR0 (10 * 8)
#define EX_TLB_SRR1 (11 * 8)
#define EX_TLB_R7 (12 * 8)
#define EX_TLB_SIZE (13 * 8)
#define START_EXCEPTION(label) \
.globl exc_##label##_book3e; \
exc_##label##_book3e:
/* TLB miss exception prolog
*
* This prolog handles re-entrancy (up to 3 levels supported in the PACA
* though we currently don't test for overflow). It provides you with a
* re-entrancy safe working space of r10...r16 and CR with r12 being used
* as the exception area pointer in the PACA for that level of re-entrancy
* and r13 containing the PACA pointer.
*
* SRR0 and SRR1 are saved, but DEAR and ESR are not, since they don't apply
* as-is for instruction exceptions. It's up to the actual exception code
* to save them as well if required.
*/
#define TLB_MISS_PROLOG \
mtspr SPRN_SPRG_TLB_SCRATCH,r12; \
mfspr r12,SPRN_SPRG_TLB_EXFRAME; \
std r10,EX_TLB_R10(r12); \
mfcr r10; \
std r11,EX_TLB_R11(r12); \
mfspr r11,SPRN_SPRG_TLB_SCRATCH; \
std r13,EX_TLB_R13(r12); \
mfspr r13,SPRN_SPRG_PACA; \
std r14,EX_TLB_R14(r12); \
Annotation
- Atlas domain: Architecture Layer / arch/powerpc.
- 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.