From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBM4N-0003dk-NB for qemu-devel@nongnu.org; Mon, 19 Aug 2013 05:48:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBM4H-0001zB-Ia for qemu-devel@nongnu.org; Mon, 19 Aug 2013 05:48:15 -0400 Message-ID: <5211E9AB.7050700@redhat.com> Date: Mon, 19 Aug 2013 11:47:23 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1375862885-12132-1-git-send-email-aik@ozlabs.ru> <520DF5B5.4050805@ozlabs.ru> <5210E6C2.1070208@redhat.com> <5211C99B.4070904@ozlabs.ru> <0E406847-EB38-4E35-9447-657BFF7FF70A@suse.de> <5211DAD3.1050602@ozlabs.ru> In-Reply-To: <5211DAD3.1050602@ozlabs.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Alexander Graf , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Paul Mackerras , David Gibson 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