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? > 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
