From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEU9F-000244-CU for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:11:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEU9B-00014J-UR for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:11:17 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:33502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEU9B-00014A-On for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:11:13 -0400 Received: by pdbqm3 with SMTP id qm3so72059000pdb.0 for ; Sun, 12 Jul 2015 20:11:13 -0700 (PDT) References: <1436327021-14744-1-git-send-email-david@gibson.dropbear.id.au> <559CA2B4.3090303@ozlabs.ru> <20150708053708.GN17857@voom.redhat.com> <559CC5DB.2030407@ozlabs.ru> <20150708064518.GO17857@voom.redhat.com> <559CCB15.3070806@ozlabs.ru> <1436373336.20526.97.camel@redhat.com> <559DDDF4.2010005@ozlabs.ru> <1436436193.20526.105.camel@redhat.com> <559F55E1.9@ozlabs.ru> <1436519990.20526.150.camel@redhat.com> From: Alexey Kardashevskiy Message-ID: <55A32C47.9070806@ozlabs.ru> Date: Mon, 13 Jul 2015 13:11:03 +1000 MIME-Version: 1.0 In-Reply-To: <1436519990.20526.150.camel@redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-ppc: Add POWER8E_v2.1 CPU model. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Bolognani , David Gibson Cc: lvivier@redhat.com, thuth@redhat.com, Michael Roth , qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org, Shivaprasad G Bhat , afaerber@suse.de On 07/10/2015 07:19 PM, Andrea Bolognani wrote: > On Fri, 2015-07-10 at 15:19 +1000, Alexey Kardashevskiy wrote: >> >>> If I'm reading the kernel source[1] correctly, there are actually >>> subtle >>> differences other than the number of cores: >>> >>> #define CPU_FTRS_POWER8 (/* Bunch of features here */) >>> #define CPU_FTRS_POWER8E (CPU_FTRS_POWER8 | CPU_FTR_PMAO_BUG) >> >> POWER8E was the first family of POWER8. Some revisions of POWER8E >> have this >> bug. The bug is that if we migrate from a good POWER8 to POWER8 with >> this >> bug, perf counters will stop working as the source kernel did not >> detect >> broken CPU and did not enable a workaround. We do not really know how >> many >> of this chips are out there (not many I believe) and how many have >> this >> bug. And also I guess that more people will be annoyed by inability >> to >> migrate rather than by broken perf. >> >> I'd leave migration enabled but it is worth mentioning somewhere in >> user's >> guide that if the user migrates a guest to POWER8E with the specific >> PVR, >> perf might break. > > David said we might be able to just apply the kernel PMAO workaround > unconditionally, which would of course be great. Even if that turns out > not to be possible, I agree with you that allowing migration is more > important than not breaking performance monitoring, and documenting > this properly should be enough. > >>> #define CPU_FTRS_POWER8_DD1 (CPU_FTRS_POWER8 & ~CPU_FTR_DBELL) >> >> This bug appears in POWER8E and POWER8 1.0 ("DD1"). The bug is that >> when a >> CPU thread wakes up after nap because of doorbell message, the >> doorbell >> interrupt is not pending. Guests cannot do nap themselves (they use >> H_CEDE >> hypercall for this), when a thread wakes up, it wakes in the host >> context >> so there is nothing to handle in the guest, it is purely for KVM to >> workaround. > > Great news! > >>> So the PVR matching, as done currently in QEMU, will include >>> POWER8DD1 >>> but exclude POWER8NVL, which according to to commit ddee09c0 and >>> the >>> code >>> above is absolutely identical to POWER8. >> >> Yeah, we have to add 0x004c0000 into the POWER8 family as well, I'll >> doublecheck. > > Okay. libvirt will soon advertise just POWER8 instead of specific > models, and will consider the POWER8 guest CPU model to be compatible > with any host having a POWER8* CPU, using the same PVR values and > masks as the kernel. Once QEMU is updated to include POWER8NVL, the > behavior will be consistent across the stack. Correct. > Just to be sure: the same applies to POWER7 as well, right? It > certainly looks so from both the kernel and QEMU code. Right. > Thanks a lot for all the precious bits of information you've provided. I've learnt a lot too :) -- Alexey