From nobody Fri May 3 08:28:24 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1575585237; cv=none; d=zohomail.com; s=zohoarc; b=ivu3c/OgeEhCvkFzGbd/bYXL7gq4PHnx8XdKqz3LtLGNNRuePnDhUSfLSYsu2Ub0S1ktLO99k5XrNNCtjpYu+h13SBbQZB3ATtimz8So8EHiA92rhXsyfTdRJfYP14pzr+qVNd3E312e1baTlRSdXe4iCbAoTxibKo/la/l8Hec= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1575585237; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=wQ0U0Mo35AMQpoF0V3z/7glK9hBMadetNa5lNBoKXJA=; b=VrU1OTkr1VzisqYVjxW3S2Az3u3BGxh31i16lkzSUECvDx2i2GEwELGVRKY2ndMhT+IZlXHrExvqteAGpQodXSG/Fw7t7JitK6n7N0EFFH3JWLUpvpJmZwzAqRPDUhel1M355KoB0PLDMc0kyrfLl/aCbteRxYmrSjABpujooOs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1575585237782617.92991999; Thu, 5 Dec 2019 14:33:57 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-89-a-9YVeprN5-9xlJCxbM4ow-1; Thu, 05 Dec 2019 17:33:55 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D6EA80256E; Thu, 5 Dec 2019 22:33:48 +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 21D1C10016EB; Thu, 5 Dec 2019 22:33:48 +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 AFDB218089CD; Thu, 5 Dec 2019 22:33:46 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xB5MXiN1022064 for ; Thu, 5 Dec 2019 17:33:44 -0500 Received: by smtp.corp.redhat.com (Postfix) id DC96F5D6C3; Thu, 5 Dec 2019 22:33:44 +0000 (UTC) Received: from localhost (ovpn-116-90.gru2.redhat.com [10.97.116.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0018A5D6BB; Thu, 5 Dec 2019 22:33:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575585236; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=wQ0U0Mo35AMQpoF0V3z/7glK9hBMadetNa5lNBoKXJA=; b=Xj/keUE7wQ0O5Pyx2JhPxKgW6alia/U39SeEx6vLByCgqNEXUvdUCDQh+Q3yW3tbFcmOud 1aRP81c1spioX+xG09L8fttPR+2xxCYkodBd6jvkK04eKjFUb3jf7KPwedVY+Zx2opwNcY mwO1zBWMZSYWayBlhDfG0zv0DpasZHk= From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Thu, 5 Dec 2019 19:33:39 -0300 Message-Id: <20191205223339.764534-1-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Cc: libvir-list@redhat.com, qemu-stable@nongnu.org, Paolo Bonzini , Jiri Denemark , Richard Henderson Subject: [libvirt] [PATCH] i386: Resolve CPU models to v1 by default 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: a-9YVeprN5-9xlJCxbM4ow-1 X-Mimecast-Spam-Score: 0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" When using `query-cpu-definitions` using `-machine none`, QEMU is resolving all CPU models to their latest versions. The actual CPU model version being used by another machine type (e.g. `pc-q35-4.0`) might be different. In theory, this was OK because the correct CPU model version is returned when using the correct `-machine` argument. Except that in practice, this breaks libvirt expectations: libvirt always use `-machine none` when checking if a CPU model is runnable, because runnability is not expected to be affected when the machine type is changed. For example, when running on a Haswell host without TSX, Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts, `query-cpu-definitions` says Haswell is runnable if using `-machine none`, but Haswell is actually not runnable using any of the `pc-*` machine types (because they resolve Haswell to Haswell-v1). In other words, we're breaking the "runnability guarantee" we promised to not break for a few releases (see qemu-deprecated.texi). To address this issue, change the default CPU model version to v1 on all machine types, so we make `query-cpu-definitions` output when using `-machine none` match the results when using `pc-*`. This will change in the future (the plan is to always return the latest CPU model version if using `-machine none`), but only after giving libvirt the opportunity to adapt. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=3D1779078 Signed-off-by: Eduardo Habkost --- I don't think this should block QEMU 4.2.0 from being tagged. The bug is present since 4.1.0, so we can fix it in 4.1.2 and/or 4.2.1. --- qemu-deprecated.texi | 8 ++++++++ target/i386/cpu.c | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 4b4b7425ac..b42d8b3c5f 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -374,6 +374,14 @@ guarantees must resolve the CPU model aliases using te ``alias-of'' field returned by the ``query-cpu-definitions'' QMP command. =20 +While those guarantees are kept, the return value of +``query-cpu-definitions'' will have existing CPU model aliases +point to a version that doesn't break runnability guarantees +(specifically, version 1 of those CPU models). In future QEMU +versions, aliases will point to newer CPU model versions +depending on the machine type, so management software must +resolve CPU model aliases before starting a virtual machine. + =20 @node Recently removed features @appendix Recently removed features diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 69f518a21a..54e7f18a09 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -3924,7 +3924,13 @@ static PropValue tcg_default_props[] =3D { }; =20 =20 -X86CPUVersion default_cpu_version =3D CPU_VERSION_LATEST; +/* + * We resolve CPU model aliases using -v1 when using "-machine + * none", but this is just for compatibility while libvirt isn't + * adapted to resolve CPU model versions before creating VMs. + * See "Runnability guarantee of CPU models" at * qemu-deprecated.texi. + */ +X86CPUVersion default_cpu_version =3D 1; =20 void x86_cpu_set_default_version(X86CPUVersion version) { --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list