* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 19 Mar 2019 at 07:36, Jia He <hejia...@gmail.com> wrote: > > > > Thanks Yury. > > > > On 2019/3/14 19:03, Yury Kotov wrote: > > > This patch isn't intended to merge. Just to reproduce a problem. > > > > > > The test for x-ignore-shread capability fails on aarch64 + tcg: > > > Memory content inconsistency at 44c00000 first_byte = 2 last_byte = 1 > > > current = d1 hit_edge = 1 > > > Memory content inconsistency at 44c01000 first_byte = 2 last_byte = 1 > > > current = 77 hit_edge = 1 > > > > > > I expected that QEMU doesn't write to guest RAM until VM starts, but it > > > happens in this test. By this patch I found what causes this problem. > > > > > > Backtrace: > > > 0 0x00007fb9e40affea in __memcpy_avx_unaligned () at > > > ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:118 > > > 1 0x000055f4a296dd84 in address_space_write_rom_internal () at > > > exec.c:3458 > > > 2 0x000055f4a296de3a in address_space_write_rom () at exec.c:3479 > > > 3 0x000055f4a2d519ff in rom_reset () at hw/core/loader.c:1101 > > > 4 0x000055f4a2d475ec in qemu_devices_reset () at hw/core/reset.c:69 > > > 5 0x000055f4a2c90a28 in qemu_system_reset () at vl.c:1675 > > > 6 0x000055f4a2c9851d in main () at vl.c:4552 > > This is expected -- as part of reset, we write the contents > of ROM blobs, ELF files loaded through -kernel, etc, to the > guest memory. It's not clear to me why that's causing a problem?
It's related to using a shared mapping for the memory , which in Yury's migration case is shared RAM on the same system from source/destination. That means the destination qemu as it starts overwrites the same memory the source is currently running out of. Dave > > more than that > > > > even in kvm mode, there is similar writing, and cause exception when > > destination VM is restoring. > > > > This is the backtrace with your debugging patch > > > > (gdb) bt > > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > > #1 0x0000ffffbe7988b4 in __GI_abort () at abort.c:79 > > #2 0x0000aaaaaae41c88 in kvm_set_phys_mem (kml=0xaaaaabef7b88, > > section=0xffffffffe0c0, add=true) at > > /root/hj/q_migrate/qemu/accel/kvm/kvm-all.c:821 > > #3 0x0000aaaaaae41d0c in kvm_region_add (listener=0xaaaaabef7b88, > > section=0xffffffffe0c0) at /root/hj/q_migrate/qemu/accel/kvm/kvm-all.c:831 > > #4 0x0000aaaaaae22ca0 in address_space_update_topology_pass > > (as=0xaaaaabd16ce0 <address_space_memory>, old_view=0xaaaaabeec150, > > new_view=0xaaaaac03d3e0, adding=true) > > at /root/hj/q_migrate/qemu/memory.c:958 > > #5 0x0000aaaaaae22fc4 in address_space_set_flatview (as=0xaaaaabd16ce0 > > <address_space_memory>) at /root/hj/q_migrate/qemu/memory.c:1034 > > #6 0x0000aaaaaae231e0 in memory_region_transaction_commit () at > > /root/hj/q_migrate/qemu/memory.c:1086 > > #7 0x0000aaaaaae26c90 in memory_region_update_container_subregions > > (subregion=0xaaaaabd81290) at /root/hj/q_migrate/qemu/memory.c:2358 > > #8 0x0000aaaaaae26d04 in memory_region_add_subregion_common > > (mr=0xaaaaabe43000, offset=1073741824, subregion=0xaaaaabd81290) at > > /root/hj/q_migrate/qemu/memory.c:2368 > > #9 0x0000aaaaaae26d3c in memory_region_add_subregion > > (mr=0xaaaaabe43000, offset=1073741824, subregion=0xaaaaabd81290) at > > /root/hj/q_migrate/qemu/memory.c:2376 > > #10 0x0000aaaaaaf63570 in machvirt_init (machine=0xaaaaabeb9c00) at > > /root/hj/q_migrate/qemu/hw/arm/virt.c:1611 > > #11 0x0000aaaaab1ff558 in machine_run_board_init > > (machine=0xaaaaabeb9c00) at hw/core/machine.c:965 > > #12 0x0000aaaaab14070c in main (argc=51, argv=0xffffffffee78, > > envp=0xfffffffff018) at vl.c:4459 > > This doesn't look like a write -- it's just the memory system > setting up the topology of the address spaces as the various > devices/ram/etc are created and put into their correct places. > > thanks > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
