Il 19/08/2013 10:44, Alexey Kardashevskiy ha scritto: >> > It means that if you use the same QEMU version with the same command >> > line on a different kernel version, your guest looks different because >> > we generate the dtb differently. > Oh. Sorry for my ignorance again, I am not playing dump or anything like > that - I do not understand how the device tree (which we cook in QEMU) on > the destination can possibly survive migration and not to be overwritten by > the one from the source. What was in the destination RAM before migration > does not matter at all (including dt), QEMU device tree is what matters but > this does not change. As it is "the same QEMU version", hypercalls are > supported anyway, the only difference where they will be handled - in the > host kernel or QEMU. What do I miss?
Nothing, I just asked to test that handling the hypercall in QEMU works. On x86 we have a similar problem, though with cpuid bits instead of the device tree. An older kernel might not support some cpuid bits, thus "-cpu SandyBridge" might have different cpuid bits depending on the host processor and kernel version. This is handled by having an "enforce" mode where "-cpu SandyBridge,enforce" will fail to start if the host processor or the kernel is not new enough. But in this case, you do not need this because the hypercall works if emulated by QEMU. I like Alex's solution of making it universally available in the dtb. Paolo
