From patchwork Tue Sep 3 21:02:00 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 1157356 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=209.51.188.17; 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 [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46NL6V009Xz9s00 for ; Wed, 4 Sep 2019 07:43:13 +1000 (AEST) Received: from localhost ([::1]:51942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5GZz-0008Kj-Mo for incoming@patchwork.ozlabs.org; Tue, 03 Sep 2019 17:43:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57022) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5Fwh-0004St-U0 for qemu-devel@nongnu.org; Tue, 03 Sep 2019 17:02:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i5Fwg-0001TL-MT for qemu-devel@nongnu.org; Tue, 03 Sep 2019 17:02:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53002) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i5Fwg-0001Sn-Ez for qemu-devel@nongnu.org; Tue, 03 Sep 2019 17:02:34 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC23E8980EA; Tue, 3 Sep 2019 21:02:33 +0000 (UTC) Received: from localhost (ovpn-116-55.gru2.redhat.com [10.97.116.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53BC319D70; Tue, 3 Sep 2019 21:02:33 +0000 (UTC) From: Eduardo Habkost To: Paolo Bonzini , Igor Mammedov , Peter Maydell , Richard Henderson , Marcel Apfelbaum , qemu-devel@nongnu.org Date: Tue, 3 Sep 2019 18:02:00 -0300 Message-Id: <20190903210201.14627-13-ehabkost@redhat.com> In-Reply-To: <20190903210201.14627-1-ehabkost@redhat.com> References: <20190903210201.14627-1-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.67]); Tue, 03 Sep 2019 21:02:33 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL v2 12/13] x86: do not advertise die-id in query-hotpluggbale-cpus if '-smp dies' is not set X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Igor Mammedov Commit 176d2cda0 (i386/cpu: Consolidate die-id validity in smp context) added new 'die-id' topology property to CPUs and exposed it via QMP command query-hotpluggable-cpus, which broke -device/device_add cpu-foo for existing users that do not support die-id/dies yet. That's would be fine if it happened to new machine type only but it also happened to old machine types, which breaks migration from old QEMU to the new one, for example following CLI: OLD-QEMU -M pc-i440fx-4.0 -smp 1,max_cpus=2 \ -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id is not able to start with new QEMU, complaining about invalid die-id. After discovering regression, the patch "pc: Don't make die-id mandatory unless necessary" makes die-id optional so old CLI would work. However it's not enough as new QEMU still exposes die-id via query-hotpluggbale-cpus QMP command, so the users that started old machine type on new QEMU, using all properties (including die-id) received from QMP command (as required), won't be able to start old QEMU using the same properties since it doesn't support die-id. Fix it by hiding die-id in query-hotpluggbale-cpus for all machine types in case '-smp dies' is not provided on CLI or -smp dies = 1', in which case smp_dies == 1 and APIC ID is calculated in default way (as it was before DIE support) so we won't need compat code as in both cases the topology provided to guest via CPUID is the same. Signed-off-by: Igor Mammedov Message-Id: <20190902120222.6179-1-imammedo@redhat.com> Reviewed-by: Eduardo Habkost Signed-off-by: Eduardo Habkost --- hw/i386/pc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index c7200b0b54..bad866fe44 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -2916,8 +2916,10 @@ static const CPUArchIdList *pc_possible_cpu_arch_ids(MachineState *ms) ms->smp.threads, &topo); ms->possible_cpus->cpus[i].props.has_socket_id = true; ms->possible_cpus->cpus[i].props.socket_id = topo.pkg_id; - ms->possible_cpus->cpus[i].props.has_die_id = true; - ms->possible_cpus->cpus[i].props.die_id = topo.die_id; + if (pcms->smp_dies > 1) { + ms->possible_cpus->cpus[i].props.has_die_id = true; + ms->possible_cpus->cpus[i].props.die_id = topo.die_id; + } ms->possible_cpus->cpus[i].props.has_core_id = true; ms->possible_cpus->cpus[i].props.core_id = topo.core_id; ms->possible_cpus->cpus[i].props.has_thread_id = true;