From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Ani Sinha <ani.sinha@nutanix.com>
Cc: Qemu-Devel <qemu-devel@nongnu.org>
Subject: Re: TOPOEXT and CentOs 7 guests
Date: Wed, 16 Oct 2019 14:37:17 +0100 [thread overview]
Message-ID: <20191016133717.GC16089@redhat.com> (raw)
In-Reply-To: <SN6PR02MB513583C0D0C43777B47910D1F1920@SN6PR02MB5135.namprd02.prod.outlook.com>
On Wed, Oct 16, 2019 at 12:51:58PM +0000, Ani Sinha wrote:
> Hi :
>
> I am looking at a patch where we disable TOPOEXT when -cpu host or -cpu max is passed to qemu :
>
> if (cpu->max_features) {
> for (w = 0; w < FEATURE_WORDS; w++) {
> /* Override only features that weren't set explicitly
> * by the user.
> */
> env->features[w] |=
> x86_cpu_get_supported_feature_word(w, cpu->migratable) &
> ~env->user_features[w] & \
> ~feature_word_info[w].no_autoenable_flags;
> }
> }
>
> https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg01641.html
>
> We are using a setup where we pass “kvm64” as the cpu model along with
> other hypervisor CPIUD capabilities as detected by libvirt to a centOS
> 7.7 guest and the guest is unable to boot. We are using a AMD EPYC
> platform and we have traced it down to TOPOEXT flag being the offending
> CPUID from the host CPU which is causing the issue. Does it makes sense
> to not enable this flag by default on all other guest CPU models as well
> except for EPYC and EPTC-IBPB?
>
> Just looking at the code very recently and thought I’d get an opinion
> from the wiser qemu community.
I don't have any insight into the particular problem cause. I do very
vaguely recall some previous bug I've seen related to AMD/topoext but
don't recall the details.
The single best advice though is to **NOT** use the 'kvm64' CPU
model. This is an *awful* CPU model that IIRC represents the lowest
common denominator of the first generation of x86 CPUs with hardware
virt. Trying to take an old CPU model and turn on an arbitarary
set of extra features is well know to cause bugs.
See our guidance on CPU models to use for AMD hosts:
https://qemu.weilnetz.de/doc/qemu-doc.html#preferred_005fcpu_005fmodels_005famd_005fx86
Essentially either use host passthrough, or use a plain named CPU model.
Only very few individual features make sense as extra things to turn
on above what the named CPU model supports. Mostly this is just side
channel vulnerability fixes, and a couple of perf related things like
pdpe1gb for huge page enablement as described in the above doc.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-10-16 13:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 12:51 TOPOEXT and CentOs 7 guests Ani Sinha
2019-10-16 13:37 ` Daniel P. Berrangé [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-10-16 12:48 Ani Sinha
2019-10-16 11:05 Ani Sinha
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=20191016133717.GC16089@redhat.com \
--to=berrange@redhat.com \
--cc=ani.sinha@nutanix.com \
--cc=qemu-devel@nongnu.org \
/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).