qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPY


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC CPU
Date: Mon, 11 Jun 2018 18:10:26 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]