From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vde8r-0004eF-Cn for qemu-devel@nongnu.org; Tue, 05 Nov 2013 05:45:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vde8j-0003kg-EY for qemu-devel@nongnu.org; Tue, 05 Nov 2013 05:45:49 -0500 Received: from mail-pd0-f175.google.com ([209.85.192.175]:40935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vde8i-0003kU-LL for qemu-devel@nongnu.org; Tue, 05 Nov 2013 05:45:40 -0500 Received: by mail-pd0-f175.google.com with SMTP id g10so8157748pdj.34 for ; Tue, 05 Nov 2013 02:45:39 -0800 (PST) Message-ID: <5278CC3E.4040907@ozlabs.ru> Date: Tue, 05 Nov 2013 21:45:18 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1380269200-8194-1-git-send-email-aik@ozlabs.ru> <67325DB7-EF06-49CD-BA79-6B44BCC20140@suse.de> <52496601.6040500@redhat.com> <5249754E.6070308@ozlabs.ru> <5278B4FC.6020503@redhat.com> <2B4B8088-FED7-43C5-A12F-2BDDDAB2A863@suse.de> <5278BFF0.8010004@redhat.com> In-Reply-To: <5278BFF0.8010004@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] spapr: add "compat" machine option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Alexander Graf Cc: "list@suse.de:PReP" , Paul Mackerras , QEMU Developers , Nikunj A Dadhania , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 11/05/2013 08:52 PM, Paolo Bonzini wrote: > Il 05/11/2013 10:16, Alexander Graf ha scritto: >> >> On 05.11.2013, at 10:06, Paolo Bonzini wrote: >> >>> Il 30/09/2013 14:57, Alexey Kardashevskiy ha scritto: >>>>>> Why is the option under -machine instead of -cpu? >>>> Because it is still the same CPU and the guest will still read the real >>>> PVR from the hardware (which it may not support but this is why we need >>>> compatibility mode). >>> >>> How do you support migration from a newer to an older CPU then? I think >>> the guest should never see anything about the hardware CPU model. >> >> POWER can't model that. It always leaks the host CPU information into the guest. It's the guest kernel's responsibility to not expose that change to user space. >> >> Yes, it's broken :). I'm not even sure there is any sensible way to do live migration between different CPU types. > > Still in my opinion it should be "-cpu", not "-machine". Even if it's > just a "virtual" CPU model. The compat option itself does not make much sense (yes we could just add yet another CPU class and that's it) but with the ibm,client-architecture-support we will have to implement this compatibility mode anyway. Since the guest can ask for a compatibility mode change, we either have to support compat option or hot-unplug all (all) CPU objects in QEMU and hotplug CPUs of the requested model. Or always reset the guest if it asked for a compatibility mode and recreate CPUs in QEMU during reset. As for me, the compat option seems simpler. -- Alexey