Re: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC CPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 11, 2018 at 05:50:30PM -0300, Eduardo Habkost wrote:
[...]
> > +        /* TOPOEXT feature requires 0x8000001E */
> > +        if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
> > +            x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001E);
> > +        }
> 
> I suggest moving this hunk to a separate patch.  I'm not 100%
> sure yet if this will require compat_props code to disable
> auto-xlevel-increase on older machine-types.

The problem here is that:
  $QEMU -machine pc-i440fx-1.3 -cpu Opteron_G4,+topoext
currently results in xlevel=0x8000001A, since QEMU 1.3.

(The same applies to all machine-types between 1.3 and 2.12)

I was hoping that we could declare topoext as non-migration-safe,
but I believe libvirt will already include "topoext" when using
"host-model" if the host CPU supports TOPOEXT.  Jiri, can you
confirm that?

We can address that with a "x-topoext-auto-xlevel" property, set
to true on all CPU models by default, and disabled by
PC_COMPAT_2_12.

The code would become:

    if (cpu->topoext_auto_xlevel && env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
        x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001E);
    }

Or, we could simply declare that "-cpu Opteron_G4,+topoext" will
never increase xlevel automatically (on any machine-type), and
change the code above to:

    if (cpu->auto_topoext && env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
        x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001E);
    }

-- 
Eduardo



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux