From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUqJ6-0003Fe-U3 for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:09:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUqJ3-0006Kd-Kw for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:09:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:23311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUqJ3-0006K9-Bz for qemu-devel@nongnu.org; Wed, 03 Aug 2016 03:09:33 -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 u7378uPV121242 for ; Wed, 3 Aug 2016 03:09:32 -0400 Received: from e06smtp09.uk.ibm.com (e06smtp09.uk.ibm.com [195.75.94.105]) by mx0a-001b2d01.pphosted.com with ESMTP id 24k0bp6q44-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 03 Aug 2016 03:09:32 -0400 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Aug 2016 08:09:30 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id E890A2190023 for ; Wed, 3 Aug 2016 08:08:53 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7379RNO29032658 for ; Wed, 3 Aug 2016 07:09:27 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u7379RNN026473 for ; Wed, 3 Aug 2016 01:09:27 -0600 Date: Wed, 3 Aug 2016 09:09:25 +0200 From: David Hildenbrand In-Reply-To: <20160802154734.GK3337@thinpad.lan.raisama.net> References: <1470139155-53900-1-git-send-email-dahi@linux.vnet.ibm.com> <1470139155-53900-26-git-send-email-dahi@linux.vnet.ibm.com> <20160802144552.GH3337@thinpad.lan.raisama.net> <20160802171554.6483ce9a@thinkpad-w530> <20160802154734.GK3337@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20160803090925.3370e1ff@thinkpad-w530> Subject: Re: [Qemu-devel] [Patch v1 25/29] qmp: add QMP interface "query-cpu-model-comparison" 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 > > > > > > > I think this is "feature subset" on the one hand and "earlier generation" > > on the other hand - at least for s390x. But it boils down to runnability I > > think: (< and > are actually quite misleading) > > It sounds like we need to clarify what are the use cases and > requirements, to find out how to document the exact meaning of > "superset" and "subset". > > I assume this is closely related to the semantics of > query-cpu-model-baseline (which I didn't review yet). In other > words: "superset" and "subset" means you can save a > query-cpu-model-baseline call because you already know modela or > modelb can be used as baseline, already. Is that correct? Depends on the order of parameters. But I think this was clarified to my reply in the cover letter. Will improve the overall explanation of query-cpu-model-comparison > > In this case, I will get back to this while reviewing and > discussing query-cpu-model-baseline. That sure makes sense, they go hand-in-hand, especially for the two commands "virsh cpu-baseline" and "virsh cpu-compare". It's all about testing/detecting runnable CPU models for different environments. [...] > > > > Other architectures are not > > > > +# supported yet. > > > > > > What if we provide a generic comparison function that does like > > > the following pseudocode: > > > > > > def basic_comparison(modela, modelb): > > > if modela.name == modelb.name: > > > if modela.props == modelb.props: > > > return "identical", [] > > > else: > > > #XXX: maybe add some extra logic to check if > > > # modela.props is a subset or superset of modelb.props? > > > return "incompatible", set(modela.props.keys(), modelb.props.keys()) > > > else: > > > return "incompatible", ["type"] > > > > > > def full_comparison(modela, modelb): > > > r,p = basic_comparison(modela, modelb) > > > if r == "incompatible": > > > try: > > > modela = expand_cpu_model(modela, "full") > > > modelb = expand_cpu_model(modelb, "full") > > > except: > > > # in case "full" expansion mode is not supported > > > return r,p > > > return basic_comparison(modela, modelb) > > > > > > > While I agree that that would be nice to have, it doesn't fit for s390x right > > now: The result on s390x does not rely on features/name only, but internal data > > we don't want to expose. > > > > e.g. z13.2 and z13s are considered identically. > > > > z13 is a subset of z13.2, although they have exactly the same > > features/properties (right now). It basically has to do with internal data > > (e.g. address bus sizes for hamax as an example) > > > > (that's where we indictate "type" under "responsible-properties" - they can > > never be made identically, you have to baseline). > > Right, I don't mean it to be enough for all architectures, but as > a basic implementation that is minimally useful when there's no > arch-specific comparison function. Then the question would be: Is it better to have a wrong result than any result? As it doesn't work on s390x, there could also be a problem with other architectures. Especially when comparing against "host", the name after expansion would give no identication about runnability. And only living with "incompatible" and "identical" might also not really be enough. While this could make sense, I'd suggest postponing such a basic comapare function until other architectures support the basics (expanding to full) and then see if this basic function would work for them (maybe x86 is a good candidate once the expanded name would not be "host" anymore). Thanks Eduardo! David