From patchwork Fri Jul 5 22:14:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eduardo Habkost X-Patchwork-Id: 1128346 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 45gVFf6pzpz9sNf for ; Sat, 6 Jul 2019 08:41:42 +1000 (AEST) Received: from localhost ([::1]:56672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjWth-0006s5-0X for incoming@patchwork.ozlabs.org; Fri, 05 Jul 2019 18:41:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55020) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjWUn-0007nD-4D for qemu-devel@nongnu.org; Fri, 05 Jul 2019 18:15:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjWUm-0003ZP-1a for qemu-devel@nongnu.org; Fri, 05 Jul 2019 18:15:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48112) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hjWUl-0003Z5-SY for qemu-devel@nongnu.org; Fri, 05 Jul 2019 18:15:55 -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 336558552E; Fri, 5 Jul 2019 22:15:55 +0000 (UTC) Received: from localhost (ovpn-116-30.gru2.redhat.com [10.97.116.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id BBC7145A8; Fri, 5 Jul 2019 22:15:54 +0000 (UTC) From: Eduardo Habkost To: Peter Maydell , Paolo Bonzini , qemu-devel@nongnu.org, Marcel Apfelbaum , Richard Henderson Date: Fri, 5 Jul 2019 19:14:40 -0300 Message-Id: <20190705221504.25166-19-ehabkost@redhat.com> In-Reply-To: <20190705221504.25166-1-ehabkost@redhat.com> References: <20190705221504.25166-1-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 05 Jul 2019 22:15:55 +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 v6 18/42] numa: deprecate implict memory distribution between nodes 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: , Cc: Igor Mammedov Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Igor Mammedov Implicit RAM distribution between nodes has exactly the same issues as: "numa: deprecate 'mem' parameter of '-numa node' option" only with QEMU being the user that's 'adding' 'mem' parameter. Deprecate it, to get it out of the way so that we could consolidate guest RAM allocation using memory backends making it consistent and possibly later on transition to using memory devices instead of adhoc memory mapping for the initial RAM. Signed-off-by: Igor Mammedov Message-Id: <1559205199-233510-4-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost --- hw/core/numa.c | 3 +++ qemu-deprecated.texi | 8 ++++++++ 2 files changed, 11 insertions(+) diff --git a/hw/core/numa.c b/hw/core/numa.c index b9e79b8c8b..cb5fdbcb1e 100644 --- a/hw/core/numa.c +++ b/hw/core/numa.c @@ -405,6 +405,9 @@ void numa_complete_configuration(MachineState *ms) if (i == nb_numa_nodes) { assert(mc->numa_auto_assign_ram); mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_size); + warn_report("Default splitting of RAM between nodes is deprecated," + " Use '-numa node,memdev' to explictly define RAM" + " allocation per node"); } numa_total = 0; diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index ba52999f7f..4a626f535d 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -104,6 +104,14 @@ In future new machine versions will not accept the option but it will still work with old machine types. User can check QAPI schema to see if the legacy option is supported by looking at MachineInfo::numa-mem-supported property. +@subsection -numa node (without memory specified) (since 4.1) + +Splitting RAM by default between NUMA nodes has the same issues as @option{mem} +parameter described above with the difference that the role of the user plays +QEMU using implicit generic or board specific splitting rule. +Use @option{memdev} with @var{memory-backend-ram} backend or @option{mem} (if +it's supported by used machine type) to define mapping explictly instead. + @section QEMU Machine Protocol (QMP) commands @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)