From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUdUc-0000RY-1Q for qemu-devel@nongnu.org; Tue, 02 Aug 2016 13:28:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUdUX-0002pZ-Px for qemu-devel@nongnu.org; Tue, 02 Aug 2016 13:28:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUdUX-0002pI-Jh for qemu-devel@nongnu.org; Tue, 02 Aug 2016 13:28:33 -0400 Date: Tue, 2 Aug 2016 14:28:30 -0300 From: Eduardo Habkost Message-ID: <20160802172830.GL3337@thinpad.lan.raisama.net> References: <1470139155-53900-1-git-send-email-dahi@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1470139155-53900-1-git-send-email-dahi@linux.vnet.ibm.com> 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 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? 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. > > --------------------------------Libvirt usecase---------------------------- > > Testing for runability: > - Simply try to start QEMU with KVM, compat machine, CPU model > - Could be done using query-cpu-model-comparison in the future. > > Identifying host model, e.g. "virsh capabilities" > - query-cpu-model-expansion on "host" with "-M none --enable-kvm" > > : > - simply copy the identified host model AFAICS, this will work out of the box only if query-cpu-model-expansion {name: "host"} return a static CPU model name in return.model.name. > > : > - "-cpu host" > > "virsh cpu-baseline": > - query-cpu-model-baseline on two models with "-M none" > > "virsh cpu-compare": > - query-cpu-model-comparison on two models with "-M none" > > There might be some cenarios where libvirt wants to convert another CPU > model to a static variant, this can be done using query-cpu-model-expansion > [...] -- Eduardo