From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 13CE3398BC2C; Fri, 22 Jan 2021 10:13:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13CE3398BC2C
From: "berrange at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/27201] Consider disabling x86-64-v2 support check
Date: Fri, 22 Jan 2021 10:13:32 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: 2.33
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: berrange at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: hjl.tools at gmail dot com
X-Bugzilla-Target-Milestone: 2.33
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-27201-131-g0Jkdmd4vJ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-27201-131@http.sourceware.org/bugzilla/>
References: <bug-27201-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: glibc-bugs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Glibc-bugs mailing list <glibc-bugs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/glibc-bugs/>
List-Help: <mailto:glibc-bugs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 10:13:33 -0000

https://sourceware.org/bugzilla/show_bug.cgi?id=3D27201

--- Comment #25 from Daniel Berrange <berrange at redhat dot com> ---
One thing that occurred to me is that QEMU could explore the idea of using =
of
its CPU model versioning to define a new version 'qemu64-v2' that includes a
more useful modern baseline of feature bits.

There is also a QEMU concept called machine types, which encode a particular
machine ABI. Machine types are versioned too, so when you provision a VM, i=
t is
set use the newest machine type version available at that point in time and
never changes thereafter.  Machine types can associate with CPU versions, to
express what version 'qemu64' will expand to.=20

IOW, it ought to be possible to make future machine types from QEMU to
reference the qemu64-v2 CPU model instead of the qemu64-v1 model. One that =
is
done existing deployed VMs will still be using qem64-v1, but newly deployed=
 VMs
would pick up qemu64-v2. If we can achieve this, it should not involve any
changes to mgmt apps.

The devil is in the detail, but I think it is worth exploring as an option.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=