From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBasI-0001xv-Ed for qemu-devel@nongnu.org; Mon, 19 Aug 2013 21:36:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBas7-0008HJ-SZ for qemu-devel@nongnu.org; Mon, 19 Aug 2013 21:36:46 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:54137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBas7-0008Gy-MG for qemu-devel@nongnu.org; Mon, 19 Aug 2013 21:36:35 -0400 Received: by mail-pa0-f47.google.com with SMTP id kl13so89405pab.34 for ; Mon, 19 Aug 2013 18:36:34 -0700 (PDT) Message-ID: <5212C81B.2090403@ozlabs.ru> Date: Tue, 20 Aug 2013 11:36:27 +1000 From: Alexey Kardashevskiy 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> <5211E9AB.7050700@redhat.com> In-Reply-To: <5211E9AB.7050700@redhat.com> 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: Paolo Bonzini Cc: Alexander Graf , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Paul Mackerras , David Gibson On 08/19/2013 07:47 PM, Paolo Bonzini wrote: > 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. Well, I was asking rather Alex :) > 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. Hm. Here we might have a problem like this is we decide to migrate from QEMU with this patch running on modern kernel to QEMU without this patch running on old kernel - for this we might want to be able to disable "multi-tce" via machine options on newer kernels. Do we care enough to add such a parameter or we just disable migration and that's it? This SandyBridge,enforce - what if the destination host running on old kernel was run without this option - will the migration fail? What is the mechanism? Do machine options migrate? I looked at target-i386/cpu.c but did not see the quick answer. > 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. The solution would be good if we did not already have H_PUT_TCE accelerated for emulated devices in the host kernel but we do have it. -- Alexey