On Mon, 14 Sept 2026 at 23:26, Matthew R. Ochs <[email protected]> wrote: > > With CMDQV enabled, resetting a guest after it enables VINTF invokes > the VINTF page0 unmap path. The resulting crash is intermittent and > has been observed on the RCU reclaim thread as: > > reboot: Restarting system > double free or corruption (!prev) > ... > #5 address_space_dispatch_free > #6 flatview_destroy > #7 call_rcu_thread > > FlatViews retain raw MemoryRegion pointers and release their references > asynchronously through RCU. The VINTF page0 unmap path removes the > subregion and immediately unparents and frees it. An old FlatView can > then access the freed region during teardown, resulting in a > use-after-free and heap corruption. > > Embed the VINTF page0 MemoryRegion in Tegra241CMDQV and tie its lifetime > to the VINTF page0 mmap. Initialize and add the region disabled after > successful vIOMMU allocation, and remove and unparent it before releasing > the mmap during allocation unwind. Guest VINTF enable and disable then > only toggle the region with memory_region_set_enabled(). New FlatViews > omit the disabled region, while old views continue to reference valid > storage. > > Keeping the region initialized across VINTF disable and reset is safe > because the vIOMMU association and its VINTF page0 mmap remain stable > once the guest CMDQ has been initialized. QEMU blocks hot-unplug of the > device that established the association, so later hot-adds reuse it > instead of associating the initialized guest CMDQ with a different host > SMMUv3. The CMDQV free_viommu path is therefore only invoked while > unwinding initial allocation, when the region is still disabled and has > never entered a FlatView. > > Fixes: 5965b81ce283 ("hw/arm/tegra241-cmdqv: Use mmap'd host VINTF page0 for > virtual VINTF page0") > Suggested-by: Shameer Kolothum <[email protected]> > Signed-off-by: Matthew R. Ochs <[email protected]> > ---
Applied to target-arm.next, thanks. -- PMM
