tools/testing/selftests/arm64/fp/za-fork-asm.S
Source file repositories/reference/linux-study-clean/tools/testing/selftests/arm64/fp/za-fork-asm.S
File Facts
- System
- Linux kernel
- Corpus path
tools/testing/selftests/arm64/fp/za-fork-asm.S- Extension
.S- Size
- 979 bytes
- Lines
- 62
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: tools
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
sme-inst.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0-only
// Copyright (C) 2021 ARM Limited.
#include "sme-inst.h"
.arch_extension sve
#define MAGIC 42
#define MAXVL 2048
#define MAXVL_B (MAXVL / 8)
.pushsection .text
.data
.align 4
scratch:
.space MAXVL_B
.popsection
.globl fork_test
fork_test:
smstart_za
// For simplicity just set one word in one vector, other tests
// cover general data corruption issues.
ldr x0, =scratch
mov x1, #MAGIC
str x1, [x0]
mov w12, wzr
_ldr_za 12, 0 // ZA.H[W12] loaded from [X0]
// Tail call into the C portion that does the fork & verify
b fork_test_c
.globl verify_fork
verify_fork:
// SVCR should have ZA=1, SM=0
mrs x0, S3_3_C4_C2_2
and x1, x0, #3
cmp x1, #2
beq 1f
mov x0, xzr
b 100f
1:
// ZA should still have the value we loaded
ldr x0, =scratch
mov w12, wzr
_str_za 12, 0 // ZA.H[W12] stored to [X0]
ldr x1, [x0]
cmp x1, #MAGIC
beq 2f
mov x0, xzr
b 100f
2:
// All tests passed
mov x0, #1
100:
ret
Annotation
- Immediate include surface: `sme-inst.h`.
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
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.