From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnZjn-0002cP-PQ for qemu-devel@nongnu.org; Thu, 22 May 2014 16:37:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnZjf-0004ws-Um for qemu-devel@nongnu.org; Thu, 22 May 2014 16:37:15 -0400 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:37583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnZjf-0004wZ-MO for qemu-devel@nongnu.org; Thu, 22 May 2014 16:37:07 -0400 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 May 2014 21:37:04 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9F1FE1B0804B for ; Thu, 22 May 2014 21:37:19 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s4MKb1OZ66322678 for ; Thu, 22 May 2014 20:37:01 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s4MKb03G027569 for ; Thu, 22 May 2014 14:37:01 -0600 Message-ID: <537E5FEB.1000103@de.ibm.com> Date: Thu, 22 May 2014 22:36:59 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1399993114-15333-1-git-send-email-mimu@linux.vnet.ibm.com> <1399993114-15333-7-git-send-email-mimu@linux.vnet.ibm.com> <5375FFB8.90504@suse.de> <20140516173907.3b1c4efa@bee> <53767590.2090605@suse.de> <20140519125339.09840b9e@bee> <5379EF78.9040209@suse.de> <20140519161811.5a17bc66@bee> <537A19F8.4060209@suse.de> <20140519190318.6f92c1bd@bee> <537A6608.8000608@suse.de> <20140520120218.38eb7181@bee> <537B2A0F.1030706@suse.de> <20140521145652.197bff21@bee> <537CA89B.6050803@suse.de> <20140522102316.653f34ba@bee> <537DBB12.6070108@redhat.com> In-Reply-To: <537DBB12.6070108@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 RFC 6/6] KVM: s390: add cpu model support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Michael Mueller , Alexander Graf Cc: linux-s390@vger.kernel.org, Eduardo Habkost , kvm@vger.kernel.org, Gleb Natapov , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, "Jason J. Herne" , Cornelia Huck , Andreas Faerber , Richard Henderson On 22/05/14 10:53, Paolo Bonzini wrote: > Il 22/05/2014 10:23, Michael Mueller ha scritto: >> On Wed, 21 May 2014 15:22:35 +0200 >> Alexander Graf wrote: >> >> I have seen the slides from Eduardo which he presented during this years >> DevConf in Brno and made my comments according the s390x implementation >> on that. Is you will see, this is mostly overlapping except for the model >> definition authority that I clearly see on qemu's side. >> >> See pdf attachment. > > More comments: > > - "Only one machine type in s390 case which is -machine s390-virtio-ccw" > > This probably should change sooner or later, as soon as the implementation becomes stable enough. Versioning is necessary for live migration across different QEMU version. Perhaps start versioning in 2.2, i.e. start making s390-virtio-ccw-2.1 an alias for s390-virtio-ccw now? > > Note that new virtio device features can appear at any time outside the s390 code, and will take part in versioning as well. > > - "No enforce option" > > Strongly suggest making enforce the only possible behavior. > > - "Not in the s390x case, because the KVM facility mask limits the cpu model specific facilities" > > What if the KVM facility mask changes? For x86, nowadays new CPUID bits are only introduced in KVM when a new processors comes out. But if we introduced an older CPUID bit, it would be a huge complication for backwards compatibility. Is it different for s390? > > Paolo > I guess we need to have a full picture here. Would this topic be suitable for the KVM call? Christian