target/arm/hvf, target/i386/hvf: Pass MR-relative offset to memory_region_set_dirty()
Both the arm and i386 hvf accelerators have the same bug in their dirty-page logging path: the address fed to memory_region_set_dirty() is computed as "<ipa,gpa>_page + xlat", but memory_region_set_dirty() expects an offset relative to the start of the resolved MemoryRegion. address_space_translate() already returns that offset in xlat, while ipa_page / gpa_page is the guest-physical (system address space) address. Adding the two together produces a bogus offset that for any non- trivial RAM size walks well past the end of the MemoryRegion's dirty bitmap. With dirty logging active (e.g. live migration on a guest with several GB of RAM), this triggers an out-of-bounds atomic write inside bitmap_set_atomic() and crashes the source QEMU as soon as the guest writes to RAM: Thread .. 'CPU N/HVF', stop reason = EXC_BAD_ACCESS ... bitmap_set_atomic at bitmap.c:213 physical_memory_set_dirty_range at physmem.c:1038 memory_region_set_dirty at memory.c:2191 hvf_handle_exception at hvf.c Fix it by passing only the MR-relative offset xlat. ipa_page / gpa_page is still the right argument to hvf_unprotect_dirty_range(), which works on the guest-physical address space. Signed-off-by: Scott J. Goldman <scottjgo@gmail.com> Link: https://lore.kernel.org/r/20260427232116.50586-2-scottjgo@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>