From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUg53-000592-9u for qemu-devel@nongnu.org; Tue, 02 Aug 2016 16:14:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUg4y-00080C-LO for qemu-devel@nongnu.org; Tue, 02 Aug 2016 16:14:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUg4y-000801-DF for qemu-devel@nongnu.org; Tue, 02 Aug 2016 16:14:20 -0400 Date: Tue, 2 Aug 2016 17:14:17 -0300 From: Eduardo Habkost Message-ID: <20160802201417.GQ3337@thinpad.lan.raisama.net> References: <1470139155-53900-1-git-send-email-dahi@linux.vnet.ibm.com> <20160802172830.GL3337@thinpad.lan.raisama.net> <20160802201234.2413a3ff@thinkpad-w530> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160802201234.2413a3ff@thinkpad-w530> Subject: Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand 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 08:12:34PM +0200, David Hildenbrand wrote: > > On Tue, Aug 02, 2016 at 01:58:46PM +0200, David Hildenbrand wrote: > > [...] > > > So we have: > > > a) "query-cpu-model-expansion" - tell us what the "host" or another CPU > > > model looks like. Either falling back to a static model or > > > completely exposing all properties. > > > > The query-cpu-model-expansion interface looks good to me. I just > > had a few comments about the interface documentation. > > > > > b) "query-cpu-model-comparison" - tell us how two CPU models compare, > > > indicating which properties were responsible for the decision. > > > c) "query-cpu-model-baseline" - create a new model out of two models, > > > taking a requested level of stability into account. > > > > I miss a clearer specifiction of what are the actual requirements > > and use cases of query-cpu-model-baseline. Is it related to > > runnability? If so, how exactly? > > cpu-baseline and cpu-compare are only needed to make > - "virsh cpu-compare" > - "virsh cpu-baseline" work > (see libvirt usecases below) > > These commands are needed to find/test runnability of a CPU model for > a cluster in bigger installations by tooling. > > As libvirt won't have details about s390x models, we have to provide > an interface so it can carry out these tasks. > > > > > Related to that (as mentioned in my reply to patch 25/29), I > > would like a clearer definintion of what "superset" and "subset" > > mean exactly, in query-cpu-model-comparison. Likewise, I would > > like to understand the requirements and use cases that make > > "superset" and "subset" useful. > > I took these definitions from libvirt directly. > > Example: core2duo against my sandybridge > $ virsh cpu-compare test.xml > Host CPU is a superset of CPU described in test.xml > > Usually, you do a "virsh cpu-compare" against your host cpu model. Chances > that the result is identical are very low. So depending on which > one is the first model, you get superset or subset. > > So > if A is a subset of B, A will run where B runs > if A is a superset of B, B will run where A runs > > That means, if "cpu-compare" (against your host!) returns "identical" or > "superset", you're good to go. If they are "incompatible" or "subset", > you will have to use cpu-baseline to create a compatible model. > > Does that answer your question? It does, thanks! We need this to be clearly specified in the QMP command documentation. Proably the "if A is a superset of B, [...]" rule is enough to unambigiously specify the semantics, while the rest of your explanation is useful to explain when/how exactly the command is useful. -- Eduardo