From nobody Sun Feb 8 05:40:49 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) client-ip=207.211.31.120; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1591814181; cv=none; d=zohomail.com; s=zohoarc; b=exKLSkl5fx1yuEiO0XS+SvCTG9YkTbYWQ+VCtuKCrIoZokjJDAqqYiZEC4z8F2E3oD7nAeQPBteNCXtfAYnjp7NsB4Ugn3RgxwBuIxTomnwkeHQA1/4bUf4VzfEIe0JzkETi0tO1dGZEocjuwowH5V9fTFYWKMEljGKL7sPIoME= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1591814181; 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; bh=SbiLjL6CsnqQcReDLaku5atsQ5bXZxPwLCpq3TMdOFs=; b=hxwtrfbXg09ICSOz5U2xHrV3QvgqSA/iw557QJTKLNw7KQO4ML6SSGTQWoy5SXKZXmW9SuHFR8GWVIBabqrTP7aSUv5RbZEhNXZQ+5AK1mfVZpTcwxSGOrTE8Y0K1najWYacqlUB2iw/aYHjG7LLwJqW5Az6x8g6I+eVsnXpMT8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by mx.zohomail.com with SMTPS id 1591814181336990.2140587274932; Wed, 10 Jun 2020 11:36:21 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-327-_rr5ZpxHNZ20d4PmuGGS0Q-1; Wed, 10 Jun 2020 14:36:18 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B24251083E89; Wed, 10 Jun 2020 18:36:12 +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 937D05D9D7; Wed, 10 Jun 2020 18:36:12 +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 5E513B34AA; Wed, 10 Jun 2020 18:36:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 05AIaADB024074 for ; Wed, 10 Jun 2020 14:36:10 -0400 Received: by smtp.corp.redhat.com (Postfix) id 51F7410F26F6; Wed, 10 Jun 2020 18:36:10 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D9C310F26F4 for ; Wed, 10 Jun 2020 18:36:10 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 34CE6811768 for ; Wed, 10 Jun 2020 18:36:10 +0000 (UTC) Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-138-ECtUHVgDP129U2cxUbY0cQ-1; Wed, 10 Jun 2020 14:36:05 -0400 Received: by mail-qv1-f42.google.com with SMTP id y9so1506083qvs.4 for ; Wed, 10 Jun 2020 11:36:05 -0700 (PDT) Received: from rekt.ibmuc.com ([2804:431:c7c6:b081:e954:9388:2ec6:d6f4]) by smtp.gmail.com with ESMTPSA id k20sm599033qtu.16.2020.06.10.11.36.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 11:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591814180; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=SbiLjL6CsnqQcReDLaku5atsQ5bXZxPwLCpq3TMdOFs=; b=VfZevJVfURwaBfHroWrJfW90aZb4+haZvhXKJmQu8nleqMVUMVL+NuJl+SDVjISl9CD3hp ntJZHKU8XjcGXXpD33cjr/ZiPgrMYnA0jPwD8TdpF5L0nf4FrHOgD2WtLu5/etkTEctFp3 Zar+pbxYYrI/CWukaiyHVmN/lSdmHuw= X-MC-Unique: _rr5ZpxHNZ20d4PmuGGS0Q-1 X-MC-Unique: ECtUHVgDP129U2cxUbY0cQ-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SbiLjL6CsnqQcReDLaku5atsQ5bXZxPwLCpq3TMdOFs=; b=snZS0wRHJHszFgUExb7c995fZo4hXHlcctagAbC3NzSYi2/dAs/nrO9q0a9j4jHiEk 5iMroosm/dnzx2tNt8Qt+jWhijUm+oeMJclL8TWTVv4GNCSnPKQ0dLPf6Q1mBMd49P+t mjo++tvS/yPuoNxMjsZinoJ4ZWOBh0fLLL+MyWW5e23IQJFoWaYZ7oULQCiVQJNd2AKE FyiOFKwwJGHesqZ51Y7abmogMkYRECHNSf+B3AuZ0Fr+yK6YYnSivexeS39f3ocqJVcG Bm0hjQPe3z5P8x6j1NIuioplW867gv9gV1N46TZJxQySsONBnFEj6kCJRHv2h1hMeJvM Zm/w== X-Gm-Message-State: AOAM530ocUvyyzqwSAaZ+9sO4N5Zew7UeqoBw0NW7O9LmneKiu6e2bIf 5QpSHMjk73vbnIk1wGMkwg0sJAnz X-Google-Smtp-Source: ABdhPJw68IUr/nKGbz7waIy0MFLmIOKNrcD63jxEMbxbmsx46+q27yevtLWJMPb4+qGAggUQnKkACA== X-Received: by 2002:ad4:4cce:: with SMTP id i14mr4376218qvz.207.1591814164943; Wed, 10 Jun 2020 11:36:04 -0700 (PDT) From: Daniel Henrique Barboza To: libvir-list@redhat.com Subject: [PATCH v2 2/4] qemu_domain.c: NUMA CPUs auto-fill for incomplete topologies Date: Wed, 10 Jun 2020 15:35:51 -0300 Message-Id: <20200610183553.466611-3-danielhb413@gmail.com> In-Reply-To: <20200610183553.466611-1-danielhb413@gmail.com> References: <20200610183553.466611-1-danielhb413@gmail.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: libvir-list@redhat.com Cc: Daniel Henrique Barboza 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.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Libvirt allows the user to define an incomplete NUMA topology, where the sum of all CPUs in each cell is less than the total of VCPUs. What ends up happening is that QEMU allocates the non-enumerated CPUs in the first NUMA node. This behavior is being flagged as 'to be deprecated' at least since QEMU commit ec78f8114bc4 ("numa: use possible_cpus for not mapped CPUs check"). In [1], Maxiwell suggested that we forbid the user to define such topologies. In his review [2], Peter Krempa pointed out that we can't break existing guests, and suggested that Libvirt should emulate the QEMU behavior of putting the remaining vCPUs in the first NUMA node in these cases. This patch implements Peter Krempa's suggestion. Since we're going to most likely end up with disjointed NUMA configuration in node 0 after the auto-fill, we're making auto-fill dependent on QEMU_CAPS_NUMA. A following patch will update the documentation not just to inform about the auto-fill mechanic with incomplete NUMA topologies, but also to discourage the user to create such topologies in the future. This approach also makes Libvirt independent of whether QEMU changes its current behavior since we're either auto-filling the CPUs in node 0 or the user (hopefully) is aware that incomplete topologies, although supported in Libvirt, are to be avoided. [1] https://www.redhat.com/archives/libvir-list/2019-June/msg00224.html [2] https://www.redhat.com/archives/libvir-list/2019-June/msg00263.html Signed-off-by: Daniel Henrique Barboza --- src/qemu/qemu_domain.c | 47 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 4 ++++ src/qemu/qemu_driver.c | 9 ++++++++ 3 files changed, 60 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 2dad823a86..76191e028b 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4963,6 +4963,50 @@ qemuDomainDefTsegPostParse(virDomainDefPtr def, } =20 =20 +/** + * qemuDomainDefNumaCPUsRectify: + * @numa: pointer to numa definition + * @maxCpus: number of CPUs this numa is supposed to have + * + * This function emulates the (to be deprecated) behavior of filling + * up in node0 with the remaining CPUs, in case of an incomplete NUMA + * setup, up to getVcpusMax. + * + * Returns: 0 on success, -1 on error + */ +int +qemuDomainDefNumaCPUsRectify(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) +{ + unsigned int vcpusMax, numacpus; + + /* QEMU_CAPS_NUMA tells us if QEMU is able to handle disjointed + * NUMA CPU ranges. The filling process will create a disjointed + * setup in node0 most of the time. Do not proceed if QEMU + * can't handle it.*/ + if (virDomainNumaGetNodeCount(def->numa) =3D=3D 0 || + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_NUMA)) + return 0; + + vcpusMax =3D virDomainDefGetVcpusMax(def); + numacpus =3D virDomainNumaGetCPUCountTotal(def->numa); + + if (numacpus < vcpusMax) { + if (virDomainNumaFillCPUsInNode(def->numa, 0, vcpusMax) < 0) + return -1; + } + + return 0; +} + + +static int +qemuDomainDefNumaCPUsPostParse(virDomainDefPtr def, + virQEMUCapsPtr qemuCaps) +{ + return qemuDomainDefNumaCPUsRectify(def, qemuCaps); +} + + static int qemuDomainDefPostParseBasic(virDomainDefPtr def, void *opaque G_GNUC_UNUSED) @@ -5049,6 +5093,9 @@ qemuDomainDefPostParse(virDomainDefPtr def, if (qemuDomainDefTsegPostParse(def, qemuCaps) < 0) return -1; =20 + if (qemuDomainDefNumaCPUsPostParse(def, qemuCaps) < 0) + return -1; + return 0; } =20 diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 41d3f1561d..e78a2b935d 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -1297,3 +1297,7 @@ qemuDomainInitializePflashStorageSource(virDomainObjP= tr vm); bool qemuDomainDiskBlockJobIsSupported(virDomainObjPtr vm, virDomainDiskDefPtr disk); + +int +qemuDomainDefNumaCPUsRectify(virDomainDefPtr def, + virQEMUCapsPtr qemuCaps); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 88517ba6a7..ff9414f3c4 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4999,6 +4999,7 @@ qemuDomainSetVcpusMax(virQEMUDriverPtr driver, unsigned int nvcpus) { g_autoptr(virQEMUDriverConfig) cfg =3D virQEMUDriverGetConfig(driver); + g_autoptr(virQEMUCaps) qemuCaps =3D NULL; unsigned int topologycpus; =20 if (def) { @@ -5029,6 +5030,14 @@ qemuDomainSetVcpusMax(virQEMUDriverPtr driver, if (virDomainDefSetVcpusMax(persistentDef, nvcpus, driver->xmlopt) < 0) return -1; =20 + /* re-adjust NUMA nodes if needed */ + if (!(qemuCaps =3D virQEMUCapsCacheLookup(driver->qemuCapsCache, + persistentDef->emulator))) + return -1; + + if (qemuDomainDefNumaCPUsRectify(persistentDef, qemuCaps) < 0) + return -1; + if (virDomainDefSave(persistentDef, driver->xmlopt, cfg->configDir) < = 0) return -1; =20 --=20 2.26.2