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