Great question—this is a really common point of confusion when transitioning from kernel-space device drivers to user-space UIO frameworks. Let’s break down your concerns step by step:

1. What UIO’s mmap() Actually Does #

First, it’s critical to understand that when you use UIO to mmap() a device’s I/O memory into user space, the Linux kernel handles the heavy lifting of configuring the memory attributes correctly for the target architecture:

• On ARM64, the kernel will map the device memory with Device-nGnRE (or similar) attributes by default: this means the region is non-cacheable, and memory accesses are strongly ordered (no CPU reordering of loads/stores to this region).
• On x86, the kernel typically uses Uncacheable (UC) or Write-Combining (WC) attributes (depending on the device’s requirements), which also disable caching and enforce specific ordering rules.

So the kernel already addresses the CPU cache and hardware-level memory reordering issues you’d handle with writel()/readl() in kernel space.

2. Is Direct Dereferencing Safe? (Compiler vs. Hardware) #

The short answer: Yes, but only if you use volatile qualifiers on your pointers. Here’s why:

• Without volatile, the compiler has no idea that this memory region maps to hardware registers (not regular RAM). It may optimize away repeated reads/writes, reorder accesses, or even eliminate accesses it deems "unnecessary"—which would break your MMIO interactions completely.
• With volatile, you’re telling the compiler to treat every access to that pointer as observable behavior (i.e., hardware can change the value behind its back, and writes have side effects), so it won’t apply those optimizations.

Architecture-Specific Considerations #

• ARM64: As you noted, device memory is almost always mapped with strong ordering attributes, so hardware won’t reorder accesses to this region. That means you don’t need explicit memory barriers (like dmb/dsb) for most cases—unless your device’s documentation specifies that certain register accesses require ordering guarantees beyond what the memory attribute provides.
• x86: UC memory accesses enforce that loads and stores to the region are not reordered relative to each other, but x86’s general memory model allows some reordering between loads/stores to UC regions and regular memory. If your user-space code mixes MMIO accesses with regular memory operations that need strict ordering, you may need to use compiler barriers (like asm volatile("" ::: "memory")) or x86-specific instructions like mfence.

3. Key Misconceptions to Correct #

• Myth: "mmap() makes MMIO regions behave like regular RAM."
  Reality: No—these are still memory-mapped hardware registers. The kernel sets the right hardware attributes, but you still have to account for the fact that reads/writes have side effects (e.g., reading a status register might clear an interrupt flag).
• Myth: "I don’t need volatile because the kernel handled memory attributes."
  Reality: Memory attributes control CPU hardware behavior, but volatile controls compiler behavior. They’re separate concerns, and you need both for safe access.

Summary #

To safely access MMIO regions via UIO in user space:

• Use volatile when declaring your pointer to the mapped region (e.g., volatile uint32_t *mmio_ptr = mmap(...);).
• Trust that the kernel has configured the correct memory attributes (cacheability, ordering) for your architecture.
• Consult your device’s datasheet: if specific register accesses require additional ordering guarantees, add compiler or hardware memory barriers as needed.

内容的提问来源于stack exchange，提问作者김태윤