From nobody Fri May 10 02:53:26 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 1708420561030337.0351961692321; Tue, 20 Feb 2024 01:16:01 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id AA9991B75; Tue, 20 Feb 2024 04:15:59 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 0207E19F6; Tue, 20 Feb 2024 04:14:25 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 321C219EB; Tue, 20 Feb 2024 04:14:17 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.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 6AF3019DA for ; Tue, 20 Feb 2024 04:14:16 -0500 (EST) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-eFy9ChQqOuO7NMrki2xWHw-1; Tue, 20 Feb 2024 04:14:13 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 F1C3D3869146 for ; Tue, 20 Feb 2024 09:14:12 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9947240C9444 for ; Tue, 20 Feb 2024 09:14:12 +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_H2,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: eFy9ChQqOuO7NMrki2xWHw-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH] domain_validate: Account for NVDIMM label size properly when checking for memory conflicts Date: Tue, 20 Feb 2024 10:14:10 +0100 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: WPIZ2FUSIPV3HSZFV6V6Q7TLJBNMI5HK X-Message-ID-Hash: WPIZ2FUSIPV3HSZFV6V6Q7TLJBNMI5HK 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: 1708420562965100001 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. Resolves: https://issues.redhat.com/browse/RHEL-4452?focusedId=3D23805174#c= omment-23805174 Signed-off-by: Michal Privoznik --- 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