qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
Date: Tue, 19 Mar 2019 10:00:04 +0000
User-agent: Mutt/1.11.3 (2019-02-01)

* Peter Maydell (address@hidden) wrote:
> 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?

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 (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
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]