From nobody Mon Apr 29 14:37:00 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 153190236776041.0936482824377; Wed, 18 Jul 2018 01:26:07 -0700 (PDT) Received: from localhost ([::1]:35353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffhmd-00072J-1E for importer@patchew.org; Wed, 18 Jul 2018 04:26:03 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffhlC-000625-Ng for qemu-devel@nongnu.org; Wed, 18 Jul 2018 04:24:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ffhl8-0005yV-Pj for qemu-devel@nongnu.org; Wed, 18 Jul 2018 04:24:34 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:32828 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ffhl8-0005wf-GO; Wed, 18 Jul 2018 04:24:30 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D16984022905; Wed, 18 Jul 2018 08:24:29 +0000 (UTC) Received: from t460s.redhat.com (ovpn-117-49.ams2.redhat.com [10.36.117.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 790D7111AF0A; Wed, 18 Jul 2018 08:24:26 +0000 (UTC) From: David Hildenbrand To: qemu-s390x@nongnu.org Date: Wed, 18 Jul 2018 10:24:25 +0200 Message-Id: <20180718082425.14834-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 18 Jul 2018 08:24:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 18 Jul 2018 08:24:29 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'david@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH] s390x/cpumodel: fix segmentation fault when baselining models X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Huth , Chris Venteicher , David Hildenbrand , Cornelia Huck , Alexander Graf , qemu-devel@nongnu.org, Christian Borntraeger , Collin Walling , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Usually, when baselining two CPU models, whereby one of them has base CPU features disabled (e.g. z14-base,msa=3Doff), we fallback to an older model that did not have these features in the base model. We always try to create a "sane" CPU model (as far as possible), and one part of it is that removing base features is no good and to be avoided. Now, if we disable base features that were part of a z900, we're out of luck. We won't find a CPU model and QEMU will segfault. This is a scenario that should never happen in real life, but it can be used to crash QEMU. So let's make something like this: { "execute": "query-cpu-model-baseline", "arguments" : { "modela": { "name": "z14-base", "props": {"esan3" : false= }}, "modelb": { "name": "z14"}} } Produce: {"return": {"model": {"name": "z900-base", "props": {"esan3": false}}}} Instead of segfaulting. This could of course be improved (e.g. to z14-base,esan3=3Dfalse), however as this ususally won't happen, let's just avoid crashes. Signed-off-by: David Hildenbrand --- target/s390x/cpu_models.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c index cfdbccf46d..13a5d4f095 100644 --- a/target/s390x/cpu_models.c +++ b/target/s390x/cpu_models.c @@ -716,6 +716,12 @@ CpuModelBaselineInfo *arch_query_cpu_model_baseline(Cp= uModelInfo *infoa, =20 model.def =3D s390_find_cpu_def(cpu_type, max_gen, max_gen_ga, model.features); + + /* models without early base features (esan3) are bad - fallback to z9= 00 */ + if (!model.def) { + model.def =3D s390_find_cpu_def(0x2064, 7, 1, NULL); + } + /* strip off features not part of the max model */ bitmap_and(model.features, model.features, model.def->full_feat, S390_FEAT_MAX); --=20 2.17.1