From nobody Sun Dec 14 06:37:36 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1751637264; cv=none; d=zohomail.com; s=zohoarc; b=OPr43aWms2RX7+Ttfx/njWne/Mx7SR3zKtaNvtb0/INQ7jCJQA+FWJCqYnRYGP6bGzFoOwiFoYte14Y4puR5auEFfbCKEZp50sZrgMRURPzV4lH8sIjYnb19f97xzB1gHqXk1rNqji4ZKRgLJd0++STLRmtnyliOOkCc69KHrKc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1751637264; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Subject:Subject:To:To:Message-Id:Cc; bh=ZMbC+sCfMAR7olo9DarElopMHKmomO0p6eQLOWkKN6c=; b=X7kNCcsRhymkyoEDeGIhD+JW4qvXtRCiqx2qMcl/LgHFKupQFjPT5Fb7ZUhRurHZOyKp7QDXW9qZm6rEgoOBfo9QRHu4eQNQ8T2osnL6l71wEfhJElXULwsX5wB4M98r8j16fb8pwz9u5W/GebZcDG8XygB3HoDMerRfEQOPuSE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1751637264544119.8487535253588; Fri, 4 Jul 2025 06:54:24 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 8D54814E6; Fri, 4 Jul 2025 09:54:23 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 608B7156A; Fri, 4 Jul 2025 09:53:20 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 75E9D13E8; Fri, 4 Jul 2025 09:53:14 -0400 (EDT) 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 E2ACB13F5 for ; Fri, 4 Jul 2025 09:53:13 -0400 (EDT) Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-403-rzXZYqDKNO6w9UjCW4mcmg-1; Fri, 04 Jul 2025 09:53:12 -0400 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CC9C019560A1 for ; Fri, 4 Jul 2025 13:53:11 +0000 (UTC) Received: from orkuz (unknown [10.45.225.129]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3A4E01800287 for ; Fri, 4 Jul 2025 13:53:10 +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=2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751637193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ohl6eW8U7vZKNBYvkwcUP3MTuwNoSNon+Gt9/CZRD8o=; b=FkKMSehMMFXnYMdUGkvVLbB82/RRbASaJ+/hf3VWbsCiIGALEfegtjZCJtvY8KXmBX3RSP /j7M/t8FUcWRrGSsiLJOjE3kYl2mWKQjsgNxD2IivOpcp2l7U0IISo6O5XuyDYJlhYY7qW xolV9R0irssmX11PDqR8rlxFqbtnA1Y= X-MC-Unique: rzXZYqDKNO6w9UjCW4mcmg-1 X-Mimecast-MFC-AGG-ID: rzXZYqDKNO6w9UjCW4mcmg_1751637191 To: devel@lists.libvirt.org Subject: [PATCH 2/6] Clarify documentation of virConnectBaselineHypervisorCPU Date: Fri, 4 Jul 2025 15:53:00 +0200 Message-ID: <43348fa97e8cb4094d0c72aec30b3d0f7451049c.1751636993.git.jdenemar@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: cfUFTm7hx0d3SMMYPPz5_bnJScY7mI-Dqi_F9BwHAu8_1751637191 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 4ZGGPDDDXKG4WVXP4LWRBAJTWNCFKDG5 X-Message-ID-Hash: 4ZGGPDDDXKG4WVXP4LWRBAJTWNCFKDG5 X-MailFrom: jdenemar@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: From: Jiri Denemark via Devel Reply-To: Jiri Denemark X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1751637265484116600 Content-Type: text/plain; charset="utf-8" From: Jiri Denemark The API was apparently never considered for being used on a host that is not represented in the input set of CPU definitions. The result is limited to the set of features and CPU models known to the host's hypervisor. This would likely not be a big issue, but thanks to a side effect of commit v3.8.0-99-g9c9620af1d usability blockers come to play as well. When converting CPU data (CPUID and MSR bits) to each named model for comparison, we disable features that block usability of the model on the current hypervisor, the rest of the features are set according to the data without taking host capabilities into account. Thus the process of comparing and selecting the most appropriate CPU model for the given data is significantly influenced by the host, but it doesn't behave as if the host CPU model was included in the input data. The documentation tried to say the result was tied to the host's hypervisor, but it wasn't very clear. Signed-off-by: Jiri Denemark --- docs/manpages/virsh.rst | 11 ++++++++--- src/libvirt-host.c | 24 +++++++++++++++--------- 2 files changed, 23 insertions(+), 12 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index e13b5020b5..7082ca773a 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1015,9 +1015,14 @@ hypervisor-cpu-baseline [--features] [--migratable] [model] =20 Compute a baseline CPU which will be compatible with all CPUs defined in a= n XML -*file* and with the CPU the hypervisor is able to provide on the host. (Th= is -is different from ``cpu-baseline`` which does not consider any hypervisor -abilities when computing the baseline CPU.) +*FILE*. This command must be called on one of the hosts described in *FILE= *. +Calling it on another host results in an undefined behavior as the compute= d CPU +model is influenced by the hypervisor (the result may use an unexpected CPU +model or some features may disabled even though they are supported on all = input +CPUs). + +This is different from ``cpu-baseline`` which does not consider any hyperv= isor +abilities when computing the baseline CPU. =20 As an alternative for *FILE* in case the XML would only contain a CPU model with no additional features the CPU model name itself can be passed as *mo= del*. diff --git a/src/libvirt-host.c b/src/libvirt-host.c index d82ff993c2..8d2107fd62 100644 --- a/src/libvirt-host.c +++ b/src/libvirt-host.c @@ -1300,24 +1300,30 @@ virConnectBaselineCPU(virConnectPtr conn, * @ncpus: number of CPUs in xmlCPUs * @flags: bitwise-OR of virConnectBaselineCPUFlags * - * Computes the most feature-rich CPU which is compatible with all given C= PUs - * and can be provided by the specified hypervisor. For best results the - * host-model CPUs as advertised by virConnectGetDomainCapabilities() shou= ld be - * passed in @xmlCPUs. Any of @emulator, @arch, @machine, and @virttype - * parameters may be NULL; libvirt will choose sensible defaults tailored = to - * the host and its current configuration. + * Computes the most feature-rich CPU which is compatible with all given C= PUs. + * This API must be called on one of the hosts specified in @xmlCPUs. Call= ing + * it on another host results in an undefined behavior as the computed CPU + * model is influenced by the hypervisor (the result may use an unexpected= CPU + * model or some features may disabled even though they are supported on a= ll + * input CPUs). * * This is different from virConnectBaselineCPU() which doesn't consider a= ny * hypervisor abilities when computing the best CPU. * + * The @xmlCPUs array should contain guest CPU definitions created from the + * host CPU model description as advertised by virConnectGetDomainCapabili= ties() + * in element. Any of @emulator, @arch, @machin= e, and + * @virttype parameters may be NULL; libvirt will choose sensible defaults + * tailored to the host and its current configuration. + * * If @ncpus =3D=3D 1, the result will be the first (and only) CPU in @xml= CPUs * tailored to what the hypervisor can support on the current host. * Specifically if this single CPU definition contains no feature elements= and * a CPU model listed as usable=3D'no' in domain capabilities XML, the res= ult * will contain a list usability blockers, i.e., a list of features that w= ould - * need to be disabled to for the model to be usable on this host. This li= st - * may contain more features than what the hypervisor reports as blockers = in - * case the CPU model definition in libvirt differs from QEMU definition. + * need to be disabled for the model to be usable on this host. This list = may + * contain more features than what the hypervisor reports as blockers in c= ase + * the CPU model definition in libvirt differs from QEMU definition. * * If @flags includes VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES then libvirt * will explicitly list all CPU features that are part of the computed CPU, --=20 2.50.0