On Thu, Jan 08, 2026 at 01:25:14PM +0000, Ross Lagerwall wrote: > It is possible for a guest to relocate the linear framebuffer by writing > to the VGA device's BAR. This causes QEMU to report an error and if the > VM is migrated, the destination QEMU hits an assertion. > The problem is that updating the BAR causes the PCI core code to call > the del region callback followed by the add region callback but the > xen-hvm code ignores the del region call and therefore the subsequent > call to xen_relocate_memory() during the add region callback fails > because the source address is not correct. > > Fix it by calling in to xen_remove_from_physmap() in response to a > del region callback for the linear framebuffer so that the subsequent > add region callback succeeds. > > Signed-off-by: Ross Lagerwall <[email protected]> > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index a6e1683885a0..fd7ef56bdba9 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -720,7 +720,8 @@ void arch_xen_set_memory(XenIOState *state, > MemoryRegionSection *section, > return; > } > > - if (log_dirty != add) { > + if (log_dirty != add && > + !(section->mr == framebuffer && start_addr > 0xbffff)) { > return; > } >
That condition and others on the path are getting convoluted, and there's a similar condition in xen_add_to_physmap(). I wonder if the condition is still useful. Anyway, it seems to be good enough. I've given a try and do see an extra "xen: unmapping vram" and "xen: mapping vram" when I migrate a guest. So all good: Reviewed-by: Anthony PERARD <[email protected]> Thanks, -- Anthony PERARD
