From nobody Tue Apr 16 15:08:30 2024 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 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1528793946120333.8778603636466; Tue, 12 Jun 2018 01:59:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4E5180A; Tue, 12 Jun 2018 08:59:03 +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 37FA32010CA6; Tue, 12 Jun 2018 08:59:03 +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 6959D1800530; Tue, 12 Jun 2018 08:59:01 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w5C8wxjq006226 for ; Tue, 12 Jun 2018 04:58:59 -0400 Received: by smtp.corp.redhat.com (Postfix) id AD656111CD36; Tue, 12 Jun 2018 08:58:59 +0000 (UTC) Received: from paraplu.localdomain (ovpn-117-237.ams2.redhat.com [10.36.117.237]) by smtp.corp.redhat.com (Postfix) with ESMTP id E4DDC111CD34; Tue, 12 Jun 2018 08:58:56 +0000 (UTC) From: Kashyap Chamarthy To: libvir-list@redhat.com Date: Tue, 12 Jun 2018 10:58:46 +0200 Message-Id: <20180612085846.10420-1-kchamart@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: libvir-list@redhat.com Cc: ehabkost@redhat.com Subject: [libvirt] [PATCH] docs: formatdomain: Note the caveats for CPU policy option "force" 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: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 12 Jun 2018 08:59:05 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Eduardo Habkost has pointed out that the current documentation of libvirt's CPU feature policy "require" vs. "force" does not match QEMU's behaviour. Update the documentation by spelling out the QEMU version dependency and explain in which scenarios the usage of "policy =3D 'force'" is applicable or not. Signed-off-by: Kashyap Chamarthy --- Wordsmithing / corrections welcome. --- docs/formatdomain.html.in | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 6912762f28..4d6c3892ee 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1566,8 +1566,17 @@ =20
force
-
The virtual CPU will claim the feature is supported regardle= ss - of it being supported by host CPU.
+
The virtual CPU will claim the feature is supported + regardless of it being supported by host CPU -- this is only + true for QEMU version older than 2.9.0. I.e. when using the + CPU mode 'host-model', libvirt identifies which CPU features + to use by looking at host CPUID. For that to take effect, it + is mandatory to use force to tell libvirt that a + said CPU feature must be used despite it not existing in the + host -- this applicable only for a very limited set of CPU + features, such as 'x2apic', virt-ssbd' (for AMD CPUs).
+
However, when using QEMU 2.9.0 and above, there should + never be any need to use force.
require
Guest creation will fail unless the feature is supported by = the host CPU or the hypervisor is able to emulate it.
--=20 2.17.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list