[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Commit 331b51 breaks live migration on FreeBSD/Xen dom0
On 14/03/2019 15:54, Roger Pau Monné wrote: > The log of the incoming QEMU is: > > qemu-system-i386: -serial pty: char device redirected to /dev/pts/4 (label > serial0) > xen: shared page at pfn feff0 > xen: buffered io page at pfn feff1 > xen: buffered io evtchn is 4 > xen_mapcache: xen_map_cache_init, nr_buckets = 8000 size 1572864 > xen_ram_alloc: do not alloc 1f800000 bytes of ram at 0 when runstate is > INMIGRATE > xen_ram_alloc: do not alloc 800000 bytes of ram at 1f800000 when runstate is > INMIGRATE > xen_ram_alloc: do not alloc 10000 bytes of ram at 20000000 when runstate is > INMIGRATE > xen_ram_alloc: do not alloc 40000 bytes of ram at 20010000 when runstate is > INMIGRATE > VNC server running on 0.0.0.0:5900 > xen: mapping vram to f0000000 - f0800000 > Replacing a dummy mapcache entry for 000000001f800000 with 00000000f0000000 > Assertion failed: (p && p == memory_region_get_ram_ptr(mr)), function > xen_add_to_physmap, file > /usr/ports/sysutils/xen-tools/work/xen-4.11.1/tools/qemu-xen/hw/i386/xen/xen-hvm.c, > line 392. > The change was supposed to be platform independent - it relies on the fact addr argument to mmap() works as expected - mmaps at the specified address. If this argument might be ignored on FreeBSD - that is a problem. Other then that the change was platform independent. You could also manually enable XEN_COMPAT_PHYSMAP while building QEMU (it's now gated on only Xen version) and see if it solves your problem. We may probably keep it enabled on FreeBSD all the time if there is no other way. Could you also print p and memory_region_get_ram_ptr(mr) so we could be sure it's mmap disregarding hint address? Igor _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |