From nobody Fri Dec 27 02:34:51 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 1707413766319941.3269961517017; Thu, 8 Feb 2024 09:36:06 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id E49DD1AA7; Thu, 8 Feb 2024 12:36:04 -0500 (EST) Received: from lists.libvirt.org.85.43.8.in-addr.arpa (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id DD97F1AAB; Thu, 8 Feb 2024 12:34:47 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 688CE1AA7; Thu, 8 Feb 2024 12:34:45 -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 C13181A9E for ; Thu, 8 Feb 2024 12:34:42 -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-357-rxHwY187OD2QULzRkGLqHg-1; Thu, 08 Feb 2024 12:34:40 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 8A6AE101FA35 for ; Thu, 8 Feb 2024 17:34:40 +0000 (UTC) Received: from harajuku.usersys.redhat.com.homenet.telecomitalia.it (unknown [10.45.224.6]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EE5071C14B04 for ; Thu, 8 Feb 2024 17:34:39 +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: rxHwY187OD2QULzRkGLqHg-1 From: Andrea Bolognani To: devel@lists.libvirt.org Subject: [PATCH v2] docs: Improve documentation for dies and clusters Date: Thu, 8 Feb 2024 18:34:37 +0100 Message-ID: <20240208173437.274686-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: XZPRVIK2UXRZKFJQNQWAGJWXBUKJVNHA X-Message-ID-Hash: XZPRVIK2UXRZKFJQNQWAGJWXBUKJVNHA X-MailFrom: abologna@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: 1707413768557100001 I've seen examples in the wild of the cluster attribute having non-zero value on x86_64. This is obviously quite confusing, but it's the information that Linux exposes to userspace and we don't really have a way to tell apart a valid die/cluster ID from a dummy one. What ultimately matters is that the underlying assumptions about topology are respected, which they are: in the x86_64 cases that I have analyzed, for example, each "cluster" contained exactly one core, so any program that would use this information to influence guest topology decisions would be unaffected by the additional level showing up in the hierarchy. In an attempt to reduce confusion, remove any reference to any specific value for the attributes having any special meaning attached to it. In fact, since there are plans to make it possible to create guests with multiple CPU clusters on x86_64, rework the note into a more generic warning cautioning users that an attribute showing up here does not imply that the same attribute can be used when defining a guest CPU topology. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrang=C3=A9 --- docs/formatcaps.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index f37532296f..68477e639f 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -74,14 +74,14 @@ The ```` element consists of the following child= elements: ``die_id`` Identifier for the die the CPU is in. =20 - Note that not all architectures support CPU dies: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, even if this attribute is present, you might not be able to + define guests with multiple CPU dies. =20 ``cluster_id`` Identifier for the cluster the CPU is in. =20 - Note that not all architectures support CPU clusters: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, even if this attribute is present, you might not be able to + define guests with multiple CPU clusters. =20 ``core_id`` Identifier for the core the CPU is in. --=20 2.43.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org