From nobody Sun Feb 8 12:38:51 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=1558079153; cv=none; d=zoho.com; s=zohoarc; b=ML4enRE8CVbJy7XNYK7nl5LILrQ8A1KhmR5qwOu3+2mldH5h7DP7ACTC8sJBouPuVX2qOACg8PoGRdBZHOVAL0bc1bXvF4nS5f35UDDJD3SE0Wq8oMrQY/4DhlcfGxGl7SJ7vs7vJ+v+A17Z++CWCPhbWo+vrMdkgDYVH2atmeI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558079153; 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=5IqM/swblBPjB+sCuum2FfRueXQ4H8SQ5NPk8JUMz1A=; b=UVDu85C9SQDFzbSe0Bx30gNZrL+SXt0SqO02ysCYrq5FdWCLJth7abCT+mC9R//5ttoJ593IMjNiz8mvWDFcyfQ0pNJ407P/BrMLZsD4jZ8xcRYQ8nPFJghJZ4BNnoydWtXhQRXuVacmMnuEA97Q7wL8yTHxbXEawOvhMWtgLjI= 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 1558079153803663.7732092537419; Fri, 17 May 2019 00:45:53 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1B04475733; Fri, 17 May 2019 07:45:47 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E3A161001DD2; Fri, 17 May 2019 07:45:46 +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 A55D9206D3; Fri, 17 May 2019 07:45:44 +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 x4H7iuhF025536 for ; Fri, 17 May 2019 03:44:56 -0400 Received: by smtp.corp.redhat.com (Postfix) id D8C5A17142; Fri, 17 May 2019 07:44:56 +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 936595D6A9; Fri, 17 May 2019 07:44:55 +0000 (UTC) From: Igor Mammedov To: qemu-devel@nongnu.org Date: Fri, 17 May 2019 09:45:18 +0200 Message-Id: <1558079119-320634-6-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 5/6] numa: deprecate 'mem' parameter of '-numa node' option 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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 17 May 2019 07:45:52 +0000 (UTC) Content-Type: text/plain; charset="utf-8" The parameter allows to configure fake NUMA topology where guest VM simulates NUMA topology but not actually getting a performance benefits from it. The same or better results could be achieved using 'memdev' parameter. In light of that any VM that uses NUMA to get its benefits should use 'memdev'. To allow transition initial RAM to device based model, deprecate 'mem' parameter as its ad-hoc partitioning of initial RAM MemoryRegion can't be translated to memdev based backend transparently to users and in compatible manner (migration wise). That will also allow to clean up a bit our numa code, leaving only 'memdev' impl. in place and several boards that use node_mem to generate FDT/ACPI description from it. Signed-off-by: Igor Mammedov --- v3: * mention "numa-mem-supported" machine property in deprecation documentation. --- numa.c | 2 ++ qemu-deprecated.texi | 16 ++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/numa.c b/numa.c index 3875e1e..2205773 100644 --- a/numa.c +++ b/numa.c @@ -121,6 +121,8 @@ static void parse_numa_node(MachineState *ms, NumaNodeO= ptions *node, =20 if (node->has_mem) { numa_info[nodenr].node_mem =3D node->mem; + warn_report("Parameter -numa node,mem is deprecated," + " use -numa node,memdev instead"); } if (node->has_memdev) { Object *o; diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 842e71b..995a96c 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -72,6 +72,22 @@ backend settings instead of environment variables. To e= ase migration to the new format, the ``-audiodev-help'' option can be used to convert the current values of the environment variables to ``-audiodev'' options. =20 +@subsection -numa node,mem=3D@var{size} (since 4.1) + +The parameter @option{mem} of @option{-numa node} is used to assign a part= of +guest RAM to a NUMA node. But when using it, it's impossible to manage spe= cified +size on the host side (like bind it to a host node, setting bind policy, .= ..), +so guest end-ups with the fake NUMA configuration with suboptiomal perform= ance. +However since 2014 there is an alternative way to assign RAM to a NUMA node +using parameter @option{memdev}, which does the same as @option{mem} and p= rovides +means to actualy manage node RAM on the host side. Use parameter @option{m= emdev} +with @var{memory-backend-ram} backend as an replacement for parameter @opt= ion{mem} +to achieve the same fake NUMA effect or a properly configured +@var{memory-backend-file} backend to actually benefit from NUMA configurat= ion. +In future new machine versions will not accept the option 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. + @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