From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUqCL-0007Dz-F4 for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:02:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUqCF-00053M-JR for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:02:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:16998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUqCF-00052t-AU for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:02:31 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u736xEUA038439 for ; Wed, 3 Aug 2016 03:02:27 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 24k0bmprvm-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 03 Aug 2016 03:02:27 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Aug 2016 08:02:25 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1A7FB1B08069 for ; Wed, 3 Aug 2016 08:03:53 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7372Mpb1966400 for ; Wed, 3 Aug 2016 07:02:22 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u7372MOq006474 for ; Wed, 3 Aug 2016 01:02:22 -0600 Date: Wed, 3 Aug 2016 09:02:19 +0200 From: David Hildenbrand In-Reply-To: <20160802153838.GJ3337@thinpad.lan.raisama.net> References: <1470139155-53900-1-git-send-email-dahi@linux.vnet.ibm.com> <1470139155-53900-25-git-send-email-dahi@linux.vnet.ibm.com> <20160802134529.GE3337@thinpad.lan.raisama.net> <20160802170405.57718508@thinkpad-w530> <20160802153838.GJ3337@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20160803090219.6b58b505@thinkpad-w530> Subject: Re: [Qemu-devel] [Patch v1 24/29] qmp: add QMP interface "query-cpu-model-expansion" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, jdenemar@redhat.com, imammedo@redhat.com, cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, fiuczy@linux.vnet.ibm.com, mimu@linux.vnet.ibm.com > On Tue, Aug 02, 2016 at 05:04:05PM +0200, David Hildenbrand wrote: > [...] > > > > > > > +# model can be used by tooling without having to specify a > > > > +# compatibility machine - e.g. when displaying the "host" model. > > > > +# All static CPU models are migration-safe. > > > > > > This is cool. Unfortunately we are not going to support it in x86 > > > very soon because we don't have any static CPU models. > > > > Well, it's all about finding a minimum set of features that one can work with. > > I assume e.g. a Phenom also always has a minimum set of features? > > We could have a very minimal CPU model that is static in x86, > yes. We just need to find out "how minimal" we can really make > it. Right. Basically, on s390x we have two types of features 1) hypervisor managed 2) non-hypervisor managed Meaning the hypervisor can blindly forward 2), but needs special implementation for 1). This implies that old releases of an hypervisor will only show 2) but not 1). We can therefore move all 2) that are made public (~99%) into the minimum model + some very old 1) that are always expected to be around nowadays. Actually going below the minimum model is possible on s390x, could just happen that e.g. Linux will not boot anymore. But the question is, if static CPU models for x86 are really needed. I assume you only make veeeery little changes to these models, so showing them without a compatibility machine should almost always give the same result. And that's the main difference to s390x. The other one is obviously that we have much more feature variance, depending under which hypervisor (LPAR/KVM/z/VM) and version we're running. > > > > > > > > > > +# > > > > +# @full: Expand all properties. The produced model is not guaranteed to be > > > > +# migration-safe, but allows tooling to get an insight and work with > > > > +# model details. > > > > > > I wonder if we really need to document it broadly as "not > > > guaranteed to be migration-safe". The returned data will be > > > migration-safe (but not static) if the CPU model being expanded > > > is migration-safe, won't it? > > > > Actually I don't think so. > > Imagine expanding host: featA=true, featB=false > > In this case, "host" is not migration-safe, so the results will > not be migration-safe. Yes, so I'll keep this remark for now. > > > > +# > > > > +# s390x supports expanding of all CPU models with all expansion types. Other > > > > +# architectures are not supported yet. > > > > > > I think this paragraph is likely to get obsolete very soon (as > > > people may forget to update it when implementing the new > > > interface on other architectures). Also, the paragraph is not > > > true until patch 27/29 is applied. > > > > > > Maybe write it as "Some architectures may not support all > > > expansion types". > > > > Agreed. And most likely x86 won't support expanding all CPU models I assume? > > It will probably support expanding all CPU models in the same way > (when using "full"). > Cool! Thanks! David