Linux内核ARM64架构下，D-cache关闭时为何需执行失效操作？

Great question! This is a defensive, architecture-compliant step rooted in ARMv8 cache behavior and real-world bootloader inconsistencies. Let's break it down clearly:

1. "D-cache off" doesn’t mean cache is empty or clean #

When the bootloader enters the kernel with D-cache disabled (via clearing the SCTLR_EL1.C bit), this only stops the CPU from using the D-cache for future memory accesses. It does NOT automatically flush or clear existing cache lines—especially dirty ones (data written to cache but not yet saved to main memory in write-back mode).

Bootloaders don’t always follow strict cache maintenance rules before disabling D-cache. Some might leave stale, dirty data lingering in cache lines that correspond to physical addresses the kernel will use (like the boot_args array).

2. Prevent data inconsistency after enabling the MMU #

The preserve_boot_args function stores critical boot parameters (such as the FDT physical address) into the boot_args array using direct physical memory access (since the MMU is off). If dirty cache lines for this address range were left by the bootloader:

• Even with D-cache off, the kernel’s writes to main memory are correct, but those dirty cache lines remain in the cache hardware.
• Later, when the kernel enables the MMU and D-cache, the CPU will prioritize the stale dirty data in cache over the valid data the kernel wrote to main memory—leading to corrupted boot parameters and a failed boot.

The __inval_dcache_area call (which executes dc ivac instructions) invalidates these cache lines: it discards any stale/dirty data, ensuring the next access to this address range will fetch the correct data directly from main memory.

3. Architecture compliance and defensive programming #

ARMv8 explicitly allows executing cache maintenance instructions even when D-cache is disabled. The Linux kernel doesn’t assume all bootloaders perfectly follow boot requirements (like fully cleaning D-cache before disabling it). This step adds a safety net to handle non-compliant or buggy bootloader behavior, guaranteeing the kernel starts with a consistent memory state.

Also, the preceding dmb sy ensures all stp store operations to boot_args have completed to main memory before invalidating the cache—so we’re only discarding stale bootloader data, not the fresh data the kernel just wrote.

内容的提问来源于stack exchange，提问作者JHM