Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Peter Maydell]

On Tue, 19 Mar 2019 at 07:36, Jia He <address@hidden> 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 (address@hidden) 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