From nobody Sun Feb 8 21:47:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1558079152; cv=none; d=zoho.com; s=zohoarc; b=TPHdGdq4DT1/St3zySd088klpkOUr+RnlY4Lud8PD+varQbH/mgIAz8K+gFBxYWRJCNlyGXosmVOabMMn8j7e9Vg8w7HpDN4KqHEZZHJ9wvzaJ17wiYTdXXxzARKkct4nQjpIt6SKzwKFdEmVijqF/Ln4D/D/yiHyN98FTBfW4Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558079152; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=vu36DATxpiS6i+OdiHIGKMDeFrsA00RojK8JkWFlZLM=; b=oTjXp4RHgm5CuU4Yexyyx5aSWMDkx7KciU5waGFoCMdhMmTnVE05yd1Bmi3soL0aL/mEuGuBeMvD+1FNT/BAlCTkkDvkd9YQMJVbUV1EXfvqIGBXdxVXdfq/wmCeTGNtQJCbN2Z/8czt4mAe8ukEcXZD6IN8/81QvoxYBI6+peA= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1558079152002573.3085747640707; Fri, 17 May 2019 00:45:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 49C8B30ADC95; Fri, 17 May 2019 07:45:45 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 206AD60BE0; Fri, 17 May 2019 07:45:44 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id CACA31806B1B; Fri, 17 May 2019 07:45:42 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x4H7iwdI025546 for ; Fri, 17 May 2019 03:44:58 -0400 Received: by smtp.corp.redhat.com (Postfix) id 7326117143; Fri, 17 May 2019 07:44:58 +0000 (UTC) Received: from dell-r430-03.lab.eng.brq.redhat.com (dell-r430-03.lab.eng.brq.redhat.com [10.37.153.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2E6AE17142; Fri, 17 May 2019 07:44:57 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Fri, 17 May 2019 09:45:19 +0200 Message-Id: <1558079119-320634-7-git-send-email-imammedo@redhat.com> In-Reply-To: <1558079119-320634-1-git-send-email-imammedo@redhat.com> References: <1558079119-320634-1-git-send-email-imammedo@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Cc: libvir-list@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com Subject: [libvirt] [PATCH v3 6/6] numa: deprecate implict memory distribution between nodes X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Fri, 17 May 2019 07:45:50 +0000 (UTC) Content-Type: text/plain; charset="utf-8" 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 of initial RAM. --- v3: - update deprecation doc, s/4.0/4.1/ - mention that legacy 'mem' option could also be used to provide explicit memory distribution for old machine types Signed-off-by: Igor Mammedov --- numa.c | 3 +++ qemu-deprecated.texi | 8 ++++++++ 2 files changed, 11 insertions(+) diff --git a/numa.c b/numa.c index 2205773..6d45a1f 100644 --- a/numa.c +++ b/numa.c @@ -409,6 +409,9 @@ void numa_complete_configuration(MachineState *ms) if (i =3D=3D nb_numa_nodes) { assert(mc->numa_auto_assign_ram); mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_siz= e); + warn_report("Default splitting of RAM between nodes is depreca= ted," + " Use '-numa node,memdev' to explictly define RAM" + " allocation per node"); } =20 numa_total =3D 0; diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 995a96c..546f722 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -88,6 +88,14 @@ In future new machine versions will not accept the optio= n but it will keep working with old machine types. User can inspect read-only machine property 'numa-mem-supported' to check if specific machine type (not) supports the = option. =20 +@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 pl= ays +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 =20 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) --=20 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list