From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, libvir-list@redhat.com,
fweimer@redhat.com, carlos@redhat.com, triegel@redhat.com,
berrange@redhat.com, jdenemar@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model
Date: Mon, 9 Jan 2017 11:35:54 +0000 [thread overview]
Message-ID: <20170109113553.GC2541@work-vm> (raw)
In-Reply-To: <20170108194041.10908-1-ehabkost@redhat.com>
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> A recent glibc commit[1] added a blacklist to ensure it won't use
> TSX on hosts that are known to have a broken TSX implementation.
>
> Our existing Haswell CPU model has a blacklisted
> family/model/stepping combination, so it has to be updated to
> make sure guests will really use TSX. This is done by patch 5/5.
>
> However, to do this safely we need to ensure the host CPU is not
> a blacklisted one, so we won't mislead guests by exposing
> known-to-be-good FMS values on a known-to-be-broken host. This is
> done by patch 3/5.
I'd just like to mke sure I understand the way this will fail in a migration;
lets say we have a guest that doesn't have the new libc and hosts
with a blacklisted CPU, and -cpu Haswell.
If I understand correctly then:
a) With 'enforce' the destination qemu will fail to start
printing an error about the host lack of tsx feature.
b) Without 'enforce' the destination will start but print
the same error as a warning, but the guest will probably
break as soon as it tries to use a tsx feature?
Any other combination?
Dave
> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359
>
> ---
> Cc: dgilbert@redhat.com
> Cc: fweimer@redhat.com
> Cc: carlos@redhat.com
> Cc: triegel@redhat.com
> Cc: berrange@redhat.com
> Cc: jdenemar@redhat.com
> Cc: pbonzini@redhat.com
>
> Eduardo Habkost (5):
> i386: Add explicit array size to x86_cpu_vendor_words2str()
> i386: host_vendor_fms() helper function
> i386/kvm: Blacklist TSX on known broken hosts
> pc: Add 2.9 machine-types
> i386: Change stepping of Haswell to non-blacklisted value
>
> include/hw/i386/pc.h | 6 ++++++
> target/i386/cpu.h | 1 +
> hw/i386/pc_piix.c | 15 ++++++++++++---
> hw/i386/pc_q35.c | 13 +++++++++++--
> target/i386/cpu.c | 32 ++++++++++++++++++++++----------
> target/i386/kvm.c | 17 +++++++++++++++++
> 6 files changed, 69 insertions(+), 15 deletions(-)
>
> --
> 2.11.0.259.g40922b1
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2017-01-09 11:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-08 19:40 [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model Eduardo Habkost
2017-01-08 19:40 ` [Qemu-devel] [PATCH 1/5] i386: Add explicit array size to x86_cpu_vendor_words2str() Eduardo Habkost
2017-01-08 19:40 ` [Qemu-devel] [PATCH 2/5] i386: host_vendor_fms() helper function Eduardo Habkost
2017-01-08 19:40 ` [Qemu-devel] [PATCH 3/5] i386/kvm: Blacklist TSX on known broken hosts Eduardo Habkost
2017-01-08 19:40 ` [Qemu-devel] [PATCH 4/5] pc: Add 2.9 machine-types Eduardo Habkost
2017-01-09 12:21 ` Laszlo Ersek
2017-01-10 4:06 ` Michael S. Tsirkin
2017-01-12 12:35 ` Eduardo Habkost
2017-01-08 19:40 ` [Qemu-devel] [PATCH 5/5] i386: Change stepping of Haswell to non-blacklisted value Eduardo Habkost
2017-01-08 19:47 ` [Qemu-devel] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model no-reply
2017-01-08 19:55 ` Eduardo Habkost
2017-01-09 11:35 ` Dr. David Alan Gilbert [this message]
2017-01-12 12:33 ` Eduardo Habkost
2017-01-12 12:38 ` Dr. David Alan Gilbert
2017-01-12 13:04 ` Eduardo Habkost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170109113553.GC2541@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=carlos@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fweimer@redhat.com \
--cc=jdenemar@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=triegel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).