From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn2Eq-0002cO-W6 for qemu-devel@nongnu.org; Thu, 22 Sep 2016 07:32:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bn2Eo-0000y6-9t for qemu-devel@nongnu.org; Thu, 22 Sep 2016 07:32:24 -0400 Message-ID: <1474542476.2857.172.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Thu, 22 Sep 2016 21:07:56 +1000 In-Reply-To: References: <20160922052105.GD7915@in.ibm.com> <1474524441.2857.159.camel@kernel.crashing.org> <20160922061514.GF7915@in.ibm.com> <1474534046.2857.166.camel@kernel.crashing.org> <87d1jw5mr0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> <1474538671.2857.169.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Nikunj A Dadhania , bharata@linux.vnet.ibm.com, aik@ozlabs.ru Cc: clg@kaod.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, david@gibson.dropbear.id.au On Thu, 2016-09-22 at 12:32 +0200, Paolo Bonzini wrote: > *However* a better fix would be to preserve the old flags for > pseries-2.6, and only set the newer flags for pseries-2.7.=C2=A0 I'm no= t > saying you have to do this, but if it's not hard (no idea) why not lear= n > how to do it right. >=20 > The design is not stupid, it's just that compatibility is harder than > you think and you are going through the same learning experiences that > x86 went though. Yeah well, the design is stupid inside target-ppc is what I meant in the sense that it should have been clearer that those flags should not have affected KVM, especially knowing that TCG still needed a lot of work to add all the proper HV stuff. Also most/all those flags concern instructions that are not relevant to the "PAPR" mode which is running the guest with HV disabled, so additionally, we might want to consider being smarter in the compare as well to make sure that only the flags relevant to guest mode are compared when the vCPU is in PAPR mode. Cheers, Ben.