From nobody Mon Feb 9 01:48:31 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=1569514858; cv=none; d=zoho.com; s=zohoarc; b=WwLuHOTRxS+ZF2l0GvM4BZ0QuwHxB54eRmaldfDfysCkvSuJMuhSo2fFMOgHU38UN/CrQZmwh3cc0pUKxKHLE1dIFOhaV3A9Jz+xcEeNMZY7EnYPHuCfXcSAoSC3TbZFHwSnVUbqblwl3x7NjViH8XVqG/x97b4+bX8TiJ3V9CA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1569514858; 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:ARC-Authentication-Results; bh=vETIFKJyZ67cGYOj5ufO9Z8rbBjOwtGapyDT1cWRcH8=; b=ckwJaLwDD+wxhxCCAzZlL8Zv7yoFxP3fVHlZkPP2HP0Wze3a96RVbxOBMMoJtIGHg1ZAuzM7oYqVGf6t9+XmhaO0FLWo3hUzWJpeyWo5/8XNMERU0LZ0ZaP//bB+ie5ffcuDxF+U877LCjE78hroAnyE4vSmGwjPS4AZX0wg1iU= 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 1569514858741595.7187876024567; Thu, 26 Sep 2019 09:20:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4320B4FCDA; Thu, 26 Sep 2019 16:20:57 +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 16F5A5C224; Thu, 26 Sep 2019 16:20:57 +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 BDEC718037CA; Thu, 26 Sep 2019 16:20:56 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x8QGEZdb003713 for ; Thu, 26 Sep 2019 12:14:35 -0400 Received: by smtp.corp.redhat.com (Postfix) id 3A8765D9D5; Thu, 26 Sep 2019 16:14:35 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id B82E85D9C3 for ; Thu, 26 Sep 2019 16:14:33 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Thu, 26 Sep 2019 18:12:23 +0200 Message-Id: <3c65d8a075578d0a86983def736fc745c4ab8727.1569514291.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 27/39] qemu: Take NVMe disks into account when calculating memlock limit 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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 26 Sep 2019 16:20:57 +0000 (UTC) Content-Type: text/plain; charset="utf-8" We have this beautiful function that does crystal ball divination. The function is named qemuDomainGetMemLockLimitBytes() and it calculates the upper limit of how much locked memory is given guest going to need. The function bases its guess on devices defined for a domain. For instance, if there is a VFIO hostdev defined then it adds 1GiB to the guessed maximum. Since NVMe disks are pretty much VFIO hostdevs (but not quite), we have to do the same sorcery. Signed-off-by: Michal Privoznik ACKed-by: Peter Krempa --- src/qemu/qemu_domain.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index f8fe430a7f..33929ce3a8 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11888,6 +11888,9 @@ getPPC64MemLockLimitBytes(virDomainDefPtr def) } } =20 + if (virDomainDefHasNVMeDisk(def)) + usesVFIO =3D true; + memory =3D virDomainDefGetMemoryTotal(def); =20 if (def->mem.max_memory) @@ -11986,6 +11989,7 @@ unsigned long long qemuDomainGetMemLockLimitBytes(virDomainDefPtr def) { unsigned long long memKB =3D 0; + bool usesVFIO =3D false; size_t i; =20 /* prefer the hard limit */ @@ -12026,11 +12030,17 @@ qemuDomainGetMemLockLimitBytes(virDomainDefPtr de= f) for (i =3D 0; i < def->nhostdevs; i++) { if (virHostdevIsVFIODevice(def->hostdevs[i]) || virHostdevIsMdevDevice(def->hostdevs[i])) { - memKB =3D virDomainDefGetMemoryTotal(def) + 1024 * 1024; - goto done; + usesVFIO =3D true; + break; } } =20 + if (virDomainDefHasNVMeDisk(def)) + usesVFIO =3D true; + + if (usesVFIO) + memKB =3D virDomainDefGetMemoryTotal(def) + 1024 * 1024; + done: return memKB << 10; } --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list