From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcgm-0005vY-2w for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:35:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFcgh-0000VD-I3 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:35:06 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:17045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcgh-0000UK-9X for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:35:03 -0400 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5M7Xt1A035031 for ; Wed, 22 Jun 2016 03:35:02 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 23qaeec6bh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Jun 2016 03:35:02 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jun 2016 08:34:59 +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 E22081B0805F for ; Wed, 22 Jun 2016 08:36:03 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5M7Yqof1966354 for ; Wed, 22 Jun 2016 07:34:52 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u5M7YpYF010462 for ; Wed, 22 Jun 2016 01:34:51 -0600 Date: Wed, 22 Jun 2016 09:34:49 +0200 From: David Hildenbrand In-Reply-To: <20160622072621.GH2450045@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> <20160622085140.06984206@thinkpad-w530> <20160622072621.GH2450045@orkuz.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20160622093449.6084d7d8@thinkpad-w530> Subject: Re: [Qemu-devel] [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 > > > > 2) Requiring a running QEMU instance to run > > > > query-cpu-model-comparison > > > > > > > > With my previous query-host-cpu proposal, the task of comparing > > > > the configuration requested by the user with host capabilities > > > > can be done directly by libvirt. This way, no extra QEMU instance > > > > needs to be run before starting a VM. > > > > > > I think we can just easily get around this by not comparing a guest CPU > > > to host (except for the explicit virConnectCompareCPU, which is not very > > > useful in its current form anyway). > > > > If there is some flexible way around that, great. But I think we (s390x) could > > life without this additional query. > > So if I understand correctly, you say you don't need the API to compare > guest CPU to host CPU, right? If so, that's exactly what I said too. > I think the coffee didn't do its work already :) . I wanted to write that we can _with_ this additional query. Meaning the involved overhead would be ok - in my opinion for s390x. What we could do to avoid one compare operation would be: a) Expand the host model b) Expand the target model (because on s390x we could have migration unsafe model) c) Work with the runnability information returned via query-cpu-definitions But as we have to do b) either way on s390x, we can directly do a compare operation. (which makes implementation a lot simpler, because libvirt then doesn't have to deal with any feature/model names). David