From nobody Sun Feb 8 21:48:29 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=1554819150; cv=none; d=zoho.com; s=zohoarc; b=VGHQH6KbPkolAxW+dMBfxyPY+7l91q7RcfPZlVJY0lDRqPuHiLcPvAjE8jdUW6CBlCG+jpX4zJP0tYlvdr4cNBQtESXJxcdYPdUnIeT//HemZxHSV17MnV3/pM/G1Uv65ijeYUQOWCFHuwevHsYEykr/TQaWeJinQUkyZsTpggU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1554819150; 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=PmO54sSGnYEszLlsvew7YUgkEJ7609Fyyvc/MfiHJRw=; b=EV9X/09yOJteZnLlOVzMIAm3wEb/V4I9eNTHk2OHH+datE4zA5ty55xfcBr/tOOYoxDsoXGYTioQI5t4YS3/dmLPwZNosyvyDbtxwRtoXqN/1zY/Ys90MA8G8Q00O61tJhk3y+AqyvXpN9SoXKKqo7DV0Z6BpLj3thxls8PYMyo= 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 1554819150370725.2099743041761; Tue, 9 Apr 2019 07:12:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77A48306641B; Tue, 9 Apr 2019 14:12:28 +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 3F5B918A99; Tue, 9 Apr 2019 14:12:28 +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 E201B181AC8F; Tue, 9 Apr 2019 14:12:27 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x39EAmW6021006 for ; Tue, 9 Apr 2019 10:10:48 -0400 Received: by smtp.corp.redhat.com (Postfix) id AC1A21992A; Tue, 9 Apr 2019 14:10:48 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0ECA419C7B; Tue, 9 Apr 2019 14:10:47 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Tue, 9 Apr 2019 16:10:38 +0200 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: libvir-list@redhat.com Cc: mkletzan@redhat.com Subject: [libvirt] [PATCH 4/4] qemuSetupCpusetCgroup: Set up cpuset.mems before execing qemu 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: , 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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 09 Apr 2019 14:12:29 +0000 (UTC) Content-Type: text/plain; charset="utf-8" It's funny how this went unnoticed for such a long time. Long story short, if a domain is configured with VIR_DOMAIN_NUMATUNE_MEM_STRICT libvirt doesn't really honour that. This is because of 7e72ac787848 after which libvirt allowed qemu to allocate memory just anywhere and only after that it used some magic involving cpuset.memory_migrate and cpuset.mems to move the memory to desired NUMA nodes. This was done in order to work around some KVM bug where KVM would fail if there wasn't a DMA zone available on the NUMA node. Well, while the work around might stopped libvirt tickling the KVM bug it also caused a bug on libvirt side: if there is not enough memory on configured NUMA node(s) then any attempt to start a domain must fail. Because of the way we play with guest memory domains can start just happily. Signed-off-by: Michal Privoznik --- src/qemu/qemu_cgroup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index b2d300b419..d6c982aeed 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -869,6 +869,9 @@ qemuSetupCpusetCgroup(virDomainObjPtr vm) if (virCgroupSetCpusetMemoryMigrate(priv->cgroup, true) < 0) return -1; =20 + if (qemuSetupCpusetMems(vm) < 0) + return -1; + return 0; } =20 --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list