From nobody Fri May 10 02:38:35 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1708444540523831.7387019790059; Tue, 20 Feb 2024 07:55:40 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 39BEA1E19; Tue, 20 Feb 2024 10:55:39 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 8F0F31C47; Tue, 20 Feb 2024 10:53:40 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 8E3611C48; Tue, 20 Feb 2024 10:53:36 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id BCE6319AD for ; Tue, 20 Feb 2024 10:53:35 -0500 (EST) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-64-0H9ZEYmmOn-drYdT-nKXgA-1; Tue, 20 Feb 2024 10:53:33 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 639F0835158 for ; Tue, 20 Feb 2024 15:53:33 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A4642166AEE for ; Tue, 20 Feb 2024 15:53:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: 0H9ZEYmmOn-drYdT-nKXgA-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH v2 1/2] domain_validate: Account for NVDIMM label size properly when checking for memory conflicts Date: Tue, 20 Feb 2024 16:53:29 +0100 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: ZEXOHGLPJCWBYICWIZTU3OE52HFFLFKR X-Message-ID-Hash: ZEXOHGLPJCWBYICWIZTU3OE52HFFLFKR X-MailFrom: mprivozn@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8"; x-default="true" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1708444540944100001 As of v9.8.0-rc1~7 we check whether two devices don't overlap (since we allow setting where a device should be mapped to). We do this pretty straightforward, by comparing start and end address of each device combination. But since only the start address is given (an exposed in the XML), the end address is computed trivially as: start + mem->size * 1024 And for majority of memory device types this works. Except for NVDIMMs. For them the device consists of two separate regions: 1) actual memory device, and 2) label. Label is where NVDIMM stores some additional information like namespaces partition and so on. But it's not mapped into the guest the same way as actual memory device. In fact, mem->size is a sum of both actual memory device and label sizes. And to make things a bit worse, both sizes are subject to alignment (either the alignsize value specified in XML, or system page size if not specified in XML). Therefore, to get the size of actual memory device we need to take mem->size and substract label size rounded up to alignment. If we don't do this we report there's an overlap between two NVDIMMs even when in reality there's none. Fixes: 3fd64fb0e236fc80ffa2cc977c0d471f11fc39bf Fixes: 91f9a9fb4fc0d34ed8d7a869de3d9f87687c3618 Resolves: https://issues.redhat.com/browse/RHEL-4452?focusedId=3D23805174#c= omment-23805174 Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- src/conf/domain_validate.c | 50 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 46479f10f2..5a9398b545 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -2225,6 +2225,52 @@ virDomainHostdevDefValidate(const virDomainHostdevDe= f *hostdev) } =20 =20 +/** + * virDomainMemoryGetMappedSize: + * @mem: memory device definition + * + * For given memory device definition (@mem) calculate size mapped into + * the guest. This is usually mem->size, except for NVDIMM where its + * label is mapped elsewhere. + * + * Returns: Number of bytes a memory device takes when mapped into a + * guest. + */ +static unsigned long long +virDomainMemoryGetMappedSize(const virDomainMemoryDef *mem) +{ + unsigned long long ret =3D mem->size; + + if (mem->model =3D=3D VIR_DOMAIN_MEMORY_MODEL_NVDIMM) { + unsigned long long alignsize =3D mem->source.nvdimm.alignsize; + unsigned long long labelsize =3D 0; + + /* For NVDIMM the situation is a bit more complicated. Firstly, + * its