From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcMe-0002Ge-Nv for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:14:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFcMZ-00049e-J8 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:14:20 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:10180 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcMZ-00049Y-DN for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:14:15 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5M7A1DG076030 for ; Wed, 22 Jun 2016 03:14:14 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 23qd1gphqr-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Jun 2016 03:14:14 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jun 2016 08:14:12 +0100 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 C5C1E1B08069 for ; Wed, 22 Jun 2016 08:15:22 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5M7EAx519333326 for ; Wed, 22 Jun 2016 07:14:11 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u5M7EANh007757 for ; Wed, 22 Jun 2016 03:14:10 -0400 Date: Wed, 22 Jun 2016 09:14:08 +0200 From: David Hildenbrand In-Reply-To: <20160622071101.GG2450045@orkuz.home> References: <1466514153-85777-1-git-send-email-dahi@linux.vnet.ibm.com> <20160621164431.GI2048@thinpad.lan.raisama.net> <20160621190144.174c93cd@thinkpad-w530> <20160621203309.GK2048@thinpad.lan.raisama.net> <20160621210949.GH4783@orkuz.home> <20160621212230.GL2048@thinpad.lan.raisama.net> <20160622071101.GG2450045@orkuz.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20160622091408.3769c438@thinkpad-w530> Subject: Re: [Qemu-devel] [libvirt] [RFC 00/28] s390x CPU models: exposing features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jiri Denemark Cc: Eduardo Habkost , qemu-devel@nongnu.org, imammedo@redhat.com, cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, fiuczy@linux.vnet.ibm.com, mimu@linux.vnet.ibm.com, libvir-list@redhat.com > On Tue, Jun 21, 2016 at 18:22:30 -0300, Eduardo Habkost wrote: > > On Tue, Jun 21, 2016 at 11:09:49PM +0200, Jiri Denemark wrote: > > [...] > > > > 1) "query-cpu-model-expansion model=host" vs "query-host-cpu": > > > > > > > > I still don't think we want to set in stone that "the result the > > > > guest sees when using -cpu host" is always the same as "what the > > > > host supports running". > > > > > > > > For example: let's assume a given architecture have two features > > > > (A and B) that are both supported by the host but can never be > > > > enabled together. For actual "-cpu host" usage, QEMU would have > > > > to choose between enabling A and B. For querying host > > > > capabilities, we still want to let management software know that > > > > either A or B are supported. > > > > > > What libvirt is really interested in is the guest CPU which would be > > > used with -cpu host. This is actually what I thought query-host-cpu was > > > all about. Perhaps because there's no difference for x86. > > > > In that case, I think it makes sense to just extend > > query-cpu-definitions or use "query-cpu-model-expansion > > model=host" instead of a query-host-cpu command. > > > > Probably query-cpu-model-expansion is better than just extending > > query-cpu-definitions, because it would allow the expansion of > > extra CPU options, like "host,migratable=off". > > Yeah, this would be even better. > > Jirka > Please be aware that we don't have anything like that on s390x, but I prepared for that requirement by being able to tell query-cpu-model-expansion how to expand (full, migratable, stable). Actually full and migratable looks the same on s390x. The plan for us is to rely on "stable" most of the time, full and migratable might be what you're looking for. David