From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bV08m-0005Ku-GH for qemu-devel@nongnu.org; Wed, 03 Aug 2016 13:39:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bV08g-0001kK-AN for qemu-devel@nongnu.org; Wed, 03 Aug 2016 13:39:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bV08g-0001jK-1l for qemu-devel@nongnu.org; Wed, 03 Aug 2016 13:39:30 -0400 Date: Wed, 3 Aug 2016 14:39:24 -0300 From: Eduardo Habkost Message-ID: <20160803173924.GU3337@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> <20160803090925.3370e1ff@thinkpad-w530> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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: 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 Wed, Aug 03, 2016 at 09:09:25AM +0200, David Hildenbrand wrote: [...] > > > > > 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). Agreed. After we have a x86 implementation, we can look into implementing a generic comparison function (but make it opt-in, instead of enabling it for all architectures at once). -- Eduardo