Re: [Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd

[Bandan Das]

Eduardo Habkost <address@hidden> writes:

> On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Krčmář wrote:
>> We already bump to level 7 if features there are requested, so do the
>> same for 0xD.

But doesn't bumping to 7 for feat[ebx] have the potential to break
ABI too ?

>> Signed-off-by: Radim Krčmář <address@hidden>
>
> This breaks guest ABI and live-migration, as CPUID data is not part of
> the migration stream (although we have considered including it in the
> future).
>
> If we are going to add more special cases like this, we must provide a
> way to make QEMU honour an explicit "level" option from the config file
> or command-line.
>
> I have considered introducing "min-[x]level" and "max-{x]level"
> properties to control automatic increasing of level/xlevel. The existing
> X86CPUDefinition.level field could just control min_level, while
> explicit "level=" on the command-line or config file would explicitly
> force a specific value. Probably setting "max-level" on machine-type
> compat code would be enough to restore the previous behavior.
>
>
>> ---
>>  If we want this behavior, we should not do it by writing a case for
>>  every level.

Agreed, we should really have a more generic way of doing this.

Bandan

>>  target-i386/cpu.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index d392cf46f517..7a32ead690d2 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -2796,6 +2796,10 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
>> **errp)
>>          env->cpuid_level = 7;
>>      }
>>  
>> +    if (env->features[FEAT_XSAVE] && env->cpuid_level < 0xd) {
>> +        env->cpuid_level = 0xd;
>> +    }
>> +
>>      /* On AMD CPUs, some CPUID[8000_0001].EDX bits must match the bits on
>>       * CPUID[1].EDX.
>>       */
>> -- 
>> 2.4.4
>>