From nobody Sun Feb 8 11:40:34 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 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=1639670507; cv=none; d=zohomail.com; s=zohoarc; b=Z7Erq4pIKNafuoLWvaJEvKC2r7MCA9SJXi0quk4Fu1pvln5CY4chh/OPly/Eo82yavLNp4jVLqHda7nqftUBjzZva+MvtKb40o4j4EI0V43VTZUr3Of0XP0Df2SdCphkNEEpUUTKd0G/ZsiKciAQxDeMs7W31GXapmRb6S6E9iE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1639670507; h=Content-Type:Content-Transfer-Encoding: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; bh=Xj8ixoAeUirRmkoMQxAYZ7bfOZQd/3+VUTCz02nzUm0=; b=TPuQwcF9oSkvf6KcceEAt0QkevSicUlsAguXkY9/act6qWvZOZf3eHrUXxkmPpU7KTMqFOJ0EKhtKO9RD493kUlN8LKw3LovPGnPrXl/K/ZG72PMXYYFiqGqk3bdbGenBwTtj+zGR63EbwDUkgf5BBWaeRGagfUabxslWZZFqx4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1639670507504579.3263732650624; Thu, 16 Dec 2021 08:01:47 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-3uNVX7sFMN2pVi-K4c7jFA-1; Thu, 16 Dec 2021 11:01:42 -0500 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id C52D112E53F6; Thu, 16 Dec 2021 16:01:32 +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 A4BA1101E5BF; Thu, 16 Dec 2021 16:01:32 +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 6DCAE4A7C8; Thu, 16 Dec 2021 16:01:32 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1BGG1Bq9005507 for ; Thu, 16 Dec 2021 11:01:11 -0500 Received: by smtp.corp.redhat.com (Postfix) id 571F51037F39; Thu, 16 Dec 2021 16:01:11 +0000 (UTC) Received: from maggie.redhat.com (unknown [10.43.2.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id D338A101E5BF for ; Thu, 16 Dec 2021 16:01:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639670506; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Xj8ixoAeUirRmkoMQxAYZ7bfOZQd/3+VUTCz02nzUm0=; b=hQ2T00Bioe8hsIRflAkmq3FXZTLuO8NFI6sHpzz/2N5FtqOcEsbU79YcPavaLZhu6pWp8s gbLjgZGjiZ+bxgwhWNJUe3Apn0I+zn88lqtjml+Ddbm7gdQb73QtebLYvswDQokLny5GEF hL2oo4loZOrp5mIZneGT1sk8QTbQ6Qc= X-MC-Unique: 3uNVX7sFMN2pVi-K4c7jFA-1 From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH v2 4/6] qemu: Explicitly forbid live changing nodeset for strict numatune Date: Thu, 16 Dec 2021 17:01:04 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1639670531658100001 Content-Type: text/plain; charset="utf-8" Let's imagine a guest that's configured with strict numatune: For guests with NUMA: Depending on machine type used (see commit v6.4.0-rc1~75) we generate either: 1) -object '{"qom-type":"memory-backend-ram","id":"ram-node0",\ "size":20971520,"host-nodes":[0],"policy":"preferred"}' \ -numa node,nodeid=3D0,cpus=3D0,memdev=3Dram-node0 or 2) -numa node,nodeid=3D0,cpus=3D0,mem=3D20480 Later, when QEMU boots up and cpuset CGroup controller is available we further restrict QEMU there too. But there's a behaviour difference hidden: while in case 1) QEMU is restricted from beginning, in case 2) it is not and thus it may happen that it will allocate memory from different NUMA node and even though CGroup will try to migrate it, it may fail to do so (e.g. because memory is locked). Therefore, one can argue that case 2) is broken. NB, case 2) is exactly what mode 'restrictive' is for. However, in case 1) we are unable to update QEMU with new host-nodes, simply because it's lacking a command to do so. For guests without NUMA: It's very close to case 2) from above. We have commit v7.10.0-rc1~163 that prevents us from outputting host-nodes when generating memory-backend-* for system memory, but that simply allows QEMU to allocate memory anywhere and then relies on CGroups to move it to desired location. Due to all of this, there is no reliable way to change nodeset for mode 'strict'. Let's forbid it. Signed-off-by: Michal Privoznik --- docs/manpages/virsh.rst | 2 +- src/libvirt-domain.c | 3 +-- src/qemu/qemu_driver.c | 35 ++++++++++++++++++++++++----------- 3 files changed, 26 insertions(+), 14 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index baee508d04..9decdee925 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -3549,7 +3549,7 @@ displayed. \'restrictive' or any valid number from the virDomainNumatuneMemMode enum in case the daemon supports it. For a running domain, the mode can't be changed, and the nodeset can be changed only if the domain was started with -a mode of either \`strict' or \`restrictive'. +\`restrictive' mode. =20 *nodeset* is a list of numa nodes used by the host for running the domain. Its syntax is a comma separated list, with '-' for ranges and '^' for diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 90b8918bb5..c36874f91e 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -2185,8 +2185,7 @@ virDomainGetMemoryParameters(virDomainPtr domain, * Changing live configuration may be possible only in some cases. For * instance, for QEMU driver the mode (VIR_DOMAIN_NUMA_MODE) can not be * changed, and changing the nodeset (VIR_DOMAIN_NUMA_NODESET) is possible - * only for VIR_DOMAIN_NUMATUNE_MEM_STRICT and - * VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE modes. + * only for VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE mode. * * Changing persistent configuration does not pose such limitations. * diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e884dde721..0354e1474c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8777,10 +8777,9 @@ qemuDomainSetNumaParamsLive(virDomainObj *vm, size_t i =3D 0; =20 if (virDomainNumatuneGetMode(vm->def->numa, -1, &mode) =3D=3D 0 && - mode !=3D VIR_DOMAIN_NUMATUNE_MEM_STRICT && mode !=3D VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", - _("change of nodeset for running domain requires st= rict or restrictive numa mode")); + _("change of nodeset for running domain requires re= strictive numa mode")); return -1; } =20 @@ -8913,17 +8912,31 @@ qemuDomainSetNumaParameters(virDomainPtr dom, goto endjob; } =20 - if (nodeset && - qemuDomainSetNumaParamsLive(vm, nodeset) < 0) - goto endjob; + if (mode =3D=3D VIR_DOMAIN_NUMATUNE_MEM_STRICT) { + virBitmap *config_nodeset =3D NULL; =20 - if (virDomainNumatuneSet(def->numa, - def->placement_mode =3D=3D - VIR_DOMAIN_CPU_PLACEMENT_MODE_STATIC, - -1, mode, nodeset) < 0) - goto endjob; + if (virDomainNumatuneMaybeGetNodeset(def->numa, priv->autoNode= set, + &config_nodeset, -1) < 0) + goto endjob; =20 - qemuDomainSaveStatus(vm); + if (!virBitmapEqual(nodeset, config_nodeset)) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("can't change nodeset for strict mode for= running domain")); + goto endjob; + } + } else { + if (nodeset && + qemuDomainSetNumaParamsLive(vm, nodeset) < 0) + goto endjob; + + if (virDomainNumatuneSet(def->numa, + def->placement_mode =3D=3D + VIR_DOMAIN_CPU_PLACEMENT_MODE_STATIC, + -1, mode, nodeset) < 0) + goto endjob; + + qemuDomainSaveStatus(vm); + } } =20 if (persistentDef) { --=20 2.32.0