From patchwork Wed Jul 18 08:24:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 945579 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41Vqvr2yH0z9s3R for ; Wed, 18 Jul 2018 18:25:12 +1000 (AEST) Received: from localhost ([::1]:35344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffhlm-00067E-2A for incoming@patchwork.ozlabs.org; Wed, 18 Jul 2018 04:25:10 -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+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Usually, when baselining two CPU models, whereby one of them has base CPU features disabled (e.g. z14-base,msa=off), 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=false), 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(CpuModelInfo *infoa, model.def = s390_find_cpu_def(cpu_type, max_gen, max_gen_ga, model.features); + + /* models without early base features (esan3) are bad - fallback to z900 */ + if (!model.def) { + model.def = 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);