Claude review: gpu: nova-core: mm: Add multi-page mapping API to VMM

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

Patch Review

The most complex patch — adds prepare/execute mapping, PTE installation, and unmapping.

**Issue — inconsistent VA range validation between `map_pages()` and `alloc_vfn_range()`:**

In `map_pages()` (line 336):
```rust
if available < required {
    return Err(EINVAL);
}
```

But in `alloc_vfn_range()` (line 190):
```rust
if range_size != size {
    return Err(EINVAL);
}
```

The outer check allows `available >= required` (surplus OK), but the inner check requires exact equality. If a caller passes a VA range slightly larger than needed, the outer check passes but the inner fails. Either both should use `<` or both should use `!=`.

**Issue — `pt_pages` draining on execute:** `install_mappings()` drains the entire `pt_pages` RBTree. Since `&mut self` prevents concurrent use, this works for single prepare/execute pairs, but sequential interleaving (prepare A, prepare B, execute A) would drain B's pages along with A's. The `&mut self` constraint makes this unlikely but not impossible if the API evolves.

**Issue — per-VFN page table walk in `prepare_map()`:** Lines 182-186 walk the page table hierarchy for every individual VFN:

```rust
for i in 0..num_pages {
    let vfn = Vfn::new(vfn_start.raw() + i_u64);
    self.ensure_single_pte_path(dev, mm, vfn, pt_pages)?;
}
```

Consecutive VFNs sharing the same PDE entries will redundantly walk and check the same PDEs. For large mappings (thousands of pages), this is O(n * depth). An optimization to skip VFNs within the same PTE-level page table would significantly improve performance.

**Design note:** The `MustExecuteGuard`/`MustUnmapGuard` drop guards that warn on leak are a good safety pattern. The `Cell<bool>` makes the types `!Sync`, which is appropriate.

---
Generated by Claude Code Patch Reviewer