TOPOEXT and CentOs 7 guests

TOPOEXT and CentOs 7 guests

[Ani Sinha]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

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.

Thanks
Ani


[-- Attachment #2: Type: text/html, Size: 2130 bytes --]

Re: TOPOEXT and CentOs 7 guests

[Daniel P. Berrangé]

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 :|

TOPOEXT and CentOs 7 guests

[Ani Sinha]

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.

Thanks
Ani

TOPOEXT and CentOs 7 guests

[Ani Sinha]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

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.

Thanks
Ani

[-- Attachment #2: Type: text/html, Size: 1910 bytes --]