From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755031AbbBTT3u (ORCPT ); Fri, 20 Feb 2015 14:29:50 -0500 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:45563 "EHLO e06smtp10.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753521AbbBTT3s (ORCPT ); Fri, 20 Feb 2015 14:29:48 -0500 Date: Fri, 20 Feb 2015 20:29:19 +0100 From: Michael Mueller To: Alexander Graf Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Gleb Natapov , Christian Borntraeger , "Jason J. Herne" , Cornelia Huck , Paolo Bonzini , Andreas Faerber , Richard Henderson Subject: Re: [Qemu-devel] [RFC PATCH v2 13/15] cpu-model/s390: Add processor property routines Message-ID: <20150220202919.29cc7b32@bee> In-Reply-To: <54E76823.9000106@suse.de> References: <1424183053-4310-1-git-send-email-mimu@linux.vnet.ibm.com> <1424183053-4310-14-git-send-email-mimu@linux.vnet.ibm.com> <54E73EB2.6050700@suse.de> <20150220163209.4e082e0b@bee> <54E76823.9000106@suse.de> Organization: IBM X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15022019-0041-0000-0000-000003525224 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Feb 2015 18:00:19 +0100 Alexander Graf wrote: > > So above s390_set/get_processor_props() the code is accelerator independent. > > Any particular reason you can't do it like PPC? That seems to be a short question... and when I started one year ago, I oriented myself on the PPC version and I'm also willing to revisit it but I can't give you a quick answer different from no currently to that. There are no PVRs for s390x CPUs and thus I came up with "pseudo PVRs": /* * bits 0-7 : CMOS generation * bits 8-9 : reserved * bits 10-11 : machine class 0=unknown 1=EC 2=BC * bits 12-15 : GA * bits 16-31 : machine type * * note: bits are named according to s390 * architecture specific endienness */ enum { CPU_S390_2064_GA1 = 0x07112064, CPU_S390_2064_GA2 = 0x07122064, CPU_S390_2064_GA3 = 0x07132064, CPU_S390_2066_GA1 = 0x07212066, CPU_S390_2084_GA1 = 0x08112084, CPU_S390_2084_GA2 = 0x08122084, CPU_S390_2084_GA3 = 0x08132084, CPU_S390_2084_GA4 = 0x08142084, CPU_S390_2084_GA5 = 0x08152084, CPU_S390_2086_GA1 = 0x08212086, CPU_S390_2086_GA2 = 0x08222086, CPU_S390_2086_GA3 = 0x08232086, CPU_S390_2094_GA1 = 0x09112094, CPU_S390_2094_GA2 = 0x09122094, CPU_S390_2094_GA3 = 0x09132094, CPU_S390_2096_GA1 = 0x09212096, CPU_S390_2096_GA2 = 0x09222096, CPU_S390_2097_GA1 = 0x0a112097, CPU_S390_2097_GA2 = 0x0a122097, CPU_S390_2097_GA3 = 0x0a132097, CPU_S390_2098_GA1 = 0x0a212098, CPU_S390_2098_GA2 = 0x0a222098, CPU_S390_2817_GA1 = 0x0b112817, CPU_S390_2817_GA2 = 0x0b122817, CPU_S390_2818_GA1 = 0x0b212818, CPU_S390_2827_GA1 = 0x0c112827, CPU_S390_2827_GA2 = 0x0c122827, CPU_S390_2828_GA1 = 0x0c212828, CPU_S390_2964_GA1 = 0x0d112964, }; And initially I had a version that was limiting the accelerator to be able to implement just them with all their properties encapsulated in the a accelerator as well. After identifying the real processor related attributes defining the model, I changed the interface such that KVM or other accelerators give hints what it is able to support in dependency of the current code version and the hosting machine and let QEMU decide how to set these attributes (cpuid,ibc,fac_list). Thus I think the implementation is now quite open and easily adoptable also for TCG and possibly others as well. Eventually the integration and also some trigger points of my code are to adjust. So coming back to your question, the answer is still no for the whole item but eventually yes if you have limited it to the s390_set/get_processor_props() triggers. But I have to look into it first again. I will do that when I'm back on Tuesday morning. Thanks and have a nice WE Michael From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOtGl-0001mY-27 for qemu-devel@nongnu.org; Fri, 20 Feb 2015 14:29:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOtGg-00033Y-TB for qemu-devel@nongnu.org; Fri, 20 Feb 2015 14:29:47 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:37976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOtGg-00032t-JU for qemu-devel@nongnu.org; Fri, 20 Feb 2015 14:29:42 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Feb 2015 19:29:41 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id C62E61B08061 for ; Fri, 20 Feb 2015 19:29:52 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t1KJTdbX5308884 for ; Fri, 20 Feb 2015 19:29:39 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t1KJTUGJ010305 for ; Fri, 20 Feb 2015 12:29:37 -0700 Date: Fri, 20 Feb 2015 20:29:19 +0100 From: Michael Mueller Message-ID: <20150220202919.29cc7b32@bee> In-Reply-To: <54E76823.9000106@suse.de> References: <1424183053-4310-1-git-send-email-mimu@linux.vnet.ibm.com> <1424183053-4310-14-git-send-email-mimu@linux.vnet.ibm.com> <54E73EB2.6050700@suse.de> <20150220163209.4e082e0b@bee> <54E76823.9000106@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 13/15] cpu-model/s390: Add processor property routines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, Gleb Natapov , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, Christian Borntraeger , "Jason J. Herne" , Cornelia Huck , Paolo Bonzini , Andreas Faerber , Richard Henderson On Fri, 20 Feb 2015 18:00:19 +0100 Alexander Graf wrote: > > So above s390_set/get_processor_props() the code is accelerator independent. > > Any particular reason you can't do it like PPC? That seems to be a short question... and when I started one year ago, I oriented myself on the PPC version and I'm also willing to revisit it but I can't give you a quick answer different from no currently to that. There are no PVRs for s390x CPUs and thus I came up with "pseudo PVRs": /* * bits 0-7 : CMOS generation * bits 8-9 : reserved * bits 10-11 : machine class 0=unknown 1=EC 2=BC * bits 12-15 : GA * bits 16-31 : machine type * * note: bits are named according to s390 * architecture specific endienness */ enum { CPU_S390_2064_GA1 = 0x07112064, CPU_S390_2064_GA2 = 0x07122064, CPU_S390_2064_GA3 = 0x07132064, CPU_S390_2066_GA1 = 0x07212066, CPU_S390_2084_GA1 = 0x08112084, CPU_S390_2084_GA2 = 0x08122084, CPU_S390_2084_GA3 = 0x08132084, CPU_S390_2084_GA4 = 0x08142084, CPU_S390_2084_GA5 = 0x08152084, CPU_S390_2086_GA1 = 0x08212086, CPU_S390_2086_GA2 = 0x08222086, CPU_S390_2086_GA3 = 0x08232086, CPU_S390_2094_GA1 = 0x09112094, CPU_S390_2094_GA2 = 0x09122094, CPU_S390_2094_GA3 = 0x09132094, CPU_S390_2096_GA1 = 0x09212096, CPU_S390_2096_GA2 = 0x09222096, CPU_S390_2097_GA1 = 0x0a112097, CPU_S390_2097_GA2 = 0x0a122097, CPU_S390_2097_GA3 = 0x0a132097, CPU_S390_2098_GA1 = 0x0a212098, CPU_S390_2098_GA2 = 0x0a222098, CPU_S390_2817_GA1 = 0x0b112817, CPU_S390_2817_GA2 = 0x0b122817, CPU_S390_2818_GA1 = 0x0b212818, CPU_S390_2827_GA1 = 0x0c112827, CPU_S390_2827_GA2 = 0x0c122827, CPU_S390_2828_GA1 = 0x0c212828, CPU_S390_2964_GA1 = 0x0d112964, }; And initially I had a version that was limiting the accelerator to be able to implement just them with all their properties encapsulated in the a accelerator as well. After identifying the real processor related attributes defining the model, I changed the interface such that KVM or other accelerators give hints what it is able to support in dependency of the current code version and the hosting machine and let QEMU decide how to set these attributes (cpuid,ibc,fac_list). Thus I think the implementation is now quite open and easily adoptable also for TCG and possibly others as well. Eventually the integration and also some trigger points of my code are to adjust. So coming back to your question, the answer is still no for the whole item but eventually yes if you have limited it to the s390_set/get_processor_props() triggers. But I have to look into it first again. I will do that when I'm back on Tuesday morning. Thanks and have a nice WE Michael