Claude review: dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Subject**: `dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory`  
**Files Modified**: `include/linux/dma-mapping.h`, `include/trace/events/dma.h`, `kernel/dma/direct.h`  
**Verdict**: ⚠️ **Needs discussion** (technically sound but questions remain)

#### Technical Review

Introduces a new DMA attribute bit (bit 11) to indicate memory has been explicitly decrypted via `set_memory_decrypted()`.

**API Design** (include/linux/dma-mapping.h:405-410):
```c
+/*
+ * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
+ * (shared) for confidential computing guests. The caller must have
+ * called set_memory_decrypted(). A struct page is required.
+ */
+#define DMA_ATTR_CC_DECRYPTED  (1UL << 11)
```

**Implementation Logic** (kernel/dma/direct.h:436-448):

The patch modifies `dma_direct_map_phys()` with this logic:
```c
if (is_swiotlb_force_bounce(dev)) {
    if (!(attrs & DMA_ATTR_CC_DECRYPTED)) {
        if (attrs & DMA_ATTR_MMIO)
            return DMA_MAPPING_ERROR;
        return swiotlb_map(dev, phys, size, dir, attrs);
    }
} else if (attrs & DMA_ATTR_CC_DECRYPTED) {
    return DMA_MAPPING_ERROR;
}
```

**Analysis**:

✅ **Correct behavior matrix**:
| Force Bounce | CC_DECRYPTED | MMIO | Action |
|--------------|--------------|------|--------|
| Yes | No | No | swiotlb_map() |
| Yes | No | Yes | ERROR |
| Yes | Yes | - | Skip swiotlb, direct map |
| No | Yes | - | ERROR |

✅ **Rationale is sound**:
- When swiotlb is force-bouncing AND memory is pre-decrypted → can skip bounce buffer
- When swiotlb is NOT force-bouncing AND CC_DECRYPTED is set → error (shouldn't happen)

**Critical Questions**:

1. **Mutual exclusivity**: Can `DMA_ATTR_CC_DECRYPTED` and `DMA_ATTR_MMIO` both be set? The code doesn't explicitly forbid it. In the force-bounce path, if both are set, we skip swiotlb but then what happens in the MMIO handling later?

2. **phys_to_dma_unencrypted() availability**: 
```c
+   } else if (attrs & DMA_ATTR_CC_DECRYPTED) {
+       dma_addr = phys_to_dma_unencrypted(dev, phys);
```
Is `phys_to_dma_unencrypted()` available on all architectures? What happens on architectures without CoCo support?

3. **Verification gap**: The comment states "The caller must have called set_memory_decrypted()" but there's no enforcement. This is trust-based. Is that acceptable for security-critical code?

4. **DMA_ATTR_SKIP_CPU_SYNC interaction**: What happens if both `DMA_ATTR_CC_DECRYPTED` and `DMA_ATTR_SKIP_CPU_SYNC` are set?

**Minor Issues**:
- Trace event addition is correct
- Documentation is clear

---

---
Generated by Claude Code Patch Reviewer