Re: [Qemu-devel] Runtime-modified DIMMs and live migration issue

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 16 Jun 2015 17:41:03 +0300
Andrey Korolyov <andrey@xdel.ru> wrote:

> > Answering back to myself - I made a wrong statement before, the
> > physical mapping *are* different with different cases, of course!
> > Therefore, the issue looks much simpler and I`d have a patch over a
> > couple of days if nobody fix this earlier.
> >
> 
> ... and another (possibly last) update. This is not a memory
> misplacement but a quirky race - if no internal workload applied to
> the virtual machine during migration, no harm is done - after its
> completion the VM passes all imaginable tests as well. If no device
> I/O is involved (perf bench numa for 1000s), guest is not falling with
> guts out as with disk-test case, just crashing a process instead:
> 
> [  784.613032] thread 0/0[2750]: segfault at 0 ip           (null) sp
> 00007fda4ea6a940 error 14 in perf_3.16[400000+144000]
> 
> I think we are facing a very interesting memory access race during a
> live migration but there are no visible reasons for it to be bound
> only for a runtime-plugged memory case. All possible cases where
> either userspace or kernel driver are involved showing null as an
> instruction pointer for trace, may be this can be a hint for someone.

I've checked logs, so far I don't see anything suspicious there
except of "acpi PNP0C80:00: Already enumerated" lines,
probably rising log level might show more info
 + upload full logs
 + enable ACPI debug info to so that dimm device's _CRS would show up
 + QEMU's CLI that was used to produce such log

wrt migration:
could you provide exact CLI args on source and destination along with
used intermediate mem hotplug commands or even better if it's just
reproduced with migration of cold-plugged dimm-s for simplification
+ steps to reproduce (and guest kernel versions).