[Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

this patch adds a probe that lists all enforceable and migrateable
CPU models to the -cpu help output. The idea is to know a priory
which CPU modules can be exposed to the user without loosing any
feature flags.

Signed-off-by: Peter Lieven <pl@kamp.de>
---
 target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index cfb8aa7..3a56d3f 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1961,6 +1961,45 @@ static void listflags(FILE *f, fprintf_function print, const char **featureset)
     }
 }
 
+/*
+ * Check if the CPU Definition is enforcable on the current host CPU
+ * and contains no unmigratable flags.
+ *
+ * Returns: true if the CPU can be enforced and migrated.
+ */
+static bool x86_cpu_enforce_and_migratable(X86CPUDefinition *def)
+{
+    int i;
+    for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) {
+        FeatureWordInfo *fw = &feature_word_info[i];
+        uint32_t eax, ebx, ecx, edx, host;
+        host_cpuid(fw->cpuid_eax, 0, &eax, &ebx, &ecx, &edx);
+        switch (fw->cpuid_reg) {
+        case R_EAX:
+            host = eax;
+            break;
+        case R_EBX:
+            host = ebx;
+            break;
+        case R_ECX:
+            host = ecx;
+            break;
+        case R_EDX:
+            host = edx;
+            break;
+        default:
+            return false;
+        }
+        if (def->features[i] & ~host) {
+            return false;
+        }
+        if (def->features[i] & fw->unmigratable_flags) {
+            return false;
+        }
+    }
+    return true;
+}
+
 /* generate CPU information. */
 void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
 {
@@ -1987,6 +2026,16 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
         listflags(f, cpu_fprintf, fw->feat_names);
         (*cpu_fprintf)(f, "\n");
     }
+
+    (*cpu_fprintf)(f, "\nEnforceable and migratable x86 CPU models in KVM mode:\n");
+    (*cpu_fprintf)(f, " ");
+    for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
+        def = &builtin_x86_defs[i];
+        if (x86_cpu_enforce_and_migratable(def)) {
+            (*cpu_fprintf)(f, " %s", def->name);
+        }
+    }
+    (*cpu_fprintf)(f, "\n");
 }
 
 CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
-- 
1.9.1

[Qemu-devel] CPU Model kvm64 and Windows2012R2

[Peter Lieven]

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

Hi,

I noticed that Win2012R2 will not boot with CPU model kvm64.
The reason is that the feature lahf_lm is missing.

Is that an error or correct?

Thanks,
Peter


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

Re: [Qemu-devel] CPU Model kvm64 and Windows2012R2

[Paolo Bonzini]

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

Hi, some very old 64-bit processors had virtualization extensions but not lahf_lm. However, they are very rare, so it is probably a good idea to add it for the 2.5 machine type.

Thanks,

Paolo

Inviato dal telefono Android mediante TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Peter Lieven [pl@kamp.de]
Received: lunedì, 24 ago 2015, 12:28
To: qemu-devel@nongnu.org
CC: pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net, ehabkost@redhat.com
Subject: CPU Model kvm64 and Windows2012R2

Hi,

I noticed that Win2012R2 will not boot with CPU model kvm64.
The reason is that the feature lahf_lm is missing.

Is that an error or correct?

Thanks,
Peter


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

Re: [Qemu-devel] CPU Model kvm64 and Windows2012R2

[Peter Lieven]

Am 24.08.2015 um 13:50 schrieb Paolo Bonzini:
> Hi, some very old 64-bit processors had virtualization extensions but not lahf_lm. However, they are very rare, so it is probably a good idea to add it for the 2.5 machine type.

Maybe same accounts for "sep" ?

Will you send a patch?

BR,
Peter

Re: [Qemu-devel] CPU Model kvm64 and Windows2012R2

[Paolo Bonzini]

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

Hi, some very old 64-bit processors had virtualization extensions but not lahf_lm. However, they are very rare, so it is probably a good idea to add it for the 2.5 machine type.

Thanks,

Paolo

Inviato dal telefono Android mediante TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Peter Lieven [pl@kamp.de]
Received: lunedì, 24 ago 2015, 12:28
To: qemu-devel@nongnu.org
CC: pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net, ehabkost@redhat.com
Subject: CPU Model kvm64 and Windows2012R2

Hi,

I noticed that Win2012R2 will not boot with CPU model kvm64.
The reason is that the feature lahf_lm is missing.

Is that an error or correct?

Thanks,
Peter


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

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Eric Blake]

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

On 08/24/2015 03:17 AM, Peter Lieven wrote:
> this patch adds a probe that lists all enforceable and migrateable
> CPU models to the -cpu help output. The idea is to know a priory
> which CPU modules can be exposed to the user without loosing any
> feature flags.
> 
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---
>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)

Is this same sort of listing available through QMP? Parsing '-cpu help'
output is undesirable from libvirt point of view.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

Am 24.08.2015 um 17:46 schrieb Eric Blake:
> On 08/24/2015 03:17 AM, Peter Lieven wrote:
>> this patch adds a probe that lists all enforceable and migrateable
>> CPU models to the -cpu help output. The idea is to know a priory
>> which CPU modules can be exposed to the user without loosing any
>> feature flags.
>>
>> Signed-off-by: Peter Lieven <pl@kamp.de>
>> ---
>>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 49 insertions(+)
> Is this same sort of listing available through QMP? Parsing '-cpu help'
> output is undesirable from libvirt point of view.
>

A good point. But is there a QMP command to list available CPU types?
In this case it should be easy to extend.

But, I wonder how to issue a QMP command before the vserver is actually
running? Is there a common way to do it?

Peter

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Eduardo Habkost]

On Mon, Aug 24, 2015 at 09:36:23PM +0200, Peter Lieven wrote:
> Am 24.08.2015 um 17:46 schrieb Eric Blake:
> > On 08/24/2015 03:17 AM, Peter Lieven wrote:
> >> this patch adds a probe that lists all enforceable and migrateable
> >> CPU models to the -cpu help output. The idea is to know a priory
> >> which CPU modules can be exposed to the user without loosing any
> >> feature flags.
> >>
> >> Signed-off-by: Peter Lieven <pl@kamp.de>
> >> ---
> >>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 49 insertions(+)
> > Is this same sort of listing available through QMP? Parsing '-cpu help'
> > output is undesirable from libvirt point of view.
> >
> 
> A good point. But is there a QMP command to list available CPU types?
> In this case it should be easy to extend.

Yes, that's query-cpu-definitions. See past discussion at:
http://thread.gmane.org/gmane.comp.emulators.qemu/332554

Some of the assumptions at that thread changed. See:
http://thread.gmane.org/gmane.comp.emulators.qemu/342582/focus=346651
That means runnability should depend only on the accelerator type, and
not on the machine-type anymore.

> 
> But, I wonder how to issue a QMP command before the vserver is actually
> running? Is there a common way to do it?

What's a vserver?

-- 
Eduardo

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

Am 26.08.2015 um 20:38 schrieb Eduardo Habkost:
> On Mon, Aug 24, 2015 at 09:36:23PM +0200, Peter Lieven wrote:
>> Am 24.08.2015 um 17:46 schrieb Eric Blake:
>>> On 08/24/2015 03:17 AM, Peter Lieven wrote:
>>>> this patch adds a probe that lists all enforceable and migrateable
>>>> CPU models to the -cpu help output. The idea is to know a priory
>>>> which CPU modules can be exposed to the user without loosing any
>>>> feature flags.
>>>>
>>>> Signed-off-by: Peter Lieven <pl@kamp.de>
>>>> ---
>>>>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 49 insertions(+)
>>> Is this same sort of listing available through QMP? Parsing '-cpu help'
>>> output is undesirable from libvirt point of view.
>>>
>> A good point. But is there a QMP command to list available CPU types?
>> In this case it should be easy to extend.
> Yes, that's query-cpu-definitions. See past discussion at:
> http://thread.gmane.org/gmane.comp.emulators.qemu/332554
>
> Some of the assumptions at that thread changed. See:
> http://thread.gmane.org/gmane.comp.emulators.qemu/342582/focus=346651
> That means runnability should depend only on the accelerator type, and
> not on the machine-type anymore.

Thanks for the pointer. But is it possible to query cpu definitions without
a running Qemu? Like passing a QMP command on the commandline and
receive the answer on stdout?

>
>> But, I wonder how to issue a QMP command before the vserver is actually
>> running? Is there a common way to do it?
> What's a vserver?
>

A Virtual Server.

Thanks,
Peter

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Eduardo Habkost]

On Wed, Aug 26, 2015 at 08:46:42PM +0200, Peter Lieven wrote:
> Am 26.08.2015 um 20:38 schrieb Eduardo Habkost:
> > On Mon, Aug 24, 2015 at 09:36:23PM +0200, Peter Lieven wrote:
> >> Am 24.08.2015 um 17:46 schrieb Eric Blake:
> >>> On 08/24/2015 03:17 AM, Peter Lieven wrote:
> >>>> this patch adds a probe that lists all enforceable and migrateable
> >>>> CPU models to the -cpu help output. The idea is to know a priory
> >>>> which CPU modules can be exposed to the user without loosing any
> >>>> feature flags.
> >>>>
> >>>> Signed-off-by: Peter Lieven <pl@kamp.de>
> >>>> ---
> >>>>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  1 file changed, 49 insertions(+)
> >>> Is this same sort of listing available through QMP? Parsing '-cpu help'
> >>> output is undesirable from libvirt point of view.
> >>>
> >> A good point. But is there a QMP command to list available CPU types?
> >> In this case it should be easy to extend.
> > Yes, that's query-cpu-definitions. See past discussion at:
> > http://thread.gmane.org/gmane.comp.emulators.qemu/332554
> >
> > Some of the assumptions at that thread changed. See:
> > http://thread.gmane.org/gmane.comp.emulators.qemu/342582/focus=346651
> > That means runnability should depend only on the accelerator type, and
> > not on the machine-type anymore.
> 
> Thanks for the pointer. But is it possible to query cpu definitions without
> a running Qemu? Like passing a QMP command on the commandline and
> receive the answer on stdout?

Well, it's impossible to check if a CPU model is runnable without running QEMU.
:)

I don't think you can send a QMP command through command-line arguments, but
you can easily start a QMP monitor on stdin/stdio.

Example:
  $ (echo '{ "execute": "qmp_capabilities" }';echo '{"execute":"query-cpu-definitions"}';echo '{"execute":"quit"}';) | ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -S -qmp stdio -machine none -nographic
  {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
  {"return": {}}
  {"return": [{"name": "Opteron_G5"}, {"name": "Opteron_G4"}, {"name": "Opteron_G3"}, {"name": "Opteron_G2"}, {"name": "Opteron_G1"}, {"name": "Broadwell"}, {"name": "Broadwell-noTSX"}, {"name": "Haswell"}, {"name": "Haswell-noTSX"}, {"name": "IvyBridge"}, {"name": "SandyBridge"}, {"name": "Westmere"}, {"name": "Nehalem"}, {"name": "Penryn"}, {"name": "Conroe"}, {"name": "n270"}, {"name": "athlon"}, {"name": "pentium3"}, {"name": "pentium2"}, {"name": "pentium"}, {"name": "486"}, {"name": "coreduo"}, {"name": "kvm32"}, {"name": "qemu32"}, {"name": "kvm64"}, {"name": "core2duo"}, {"name": "phenom"}, {"name": "qemu64"}]}
  {"return": {}}
  {"timestamp": {"seconds": 1440615228, "microseconds": 854114}, "event": "SHUTDOWN"}
  $ 


> 
> >
> >> But, I wonder how to issue a QMP command before the vserver is actually
> >> running? Is there a common way to do it?
> > What's a vserver?
> >
> 
> A Virtual Server.

You mean the virtual machine? Yes, it is possible to run QMP commands before
the machine is running (you just need to use -S). You can also use "-machine
none" if you don't want any machine-specific initialization code to run at all.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

> Am 26.08.2015 um 21:00 schrieb Eduardo Habkost <ehabkost@redhat.com>:
> 
>> On Wed, Aug 26, 2015 at 08:46:42PM +0200, Peter Lieven wrote:
>>> Am 26.08.2015 um 20:38 schrieb Eduardo Habkost:
>>>> On Mon, Aug 24, 2015 at 09:36:23PM +0200, Peter Lieven wrote:
>>>>> Am 24.08.2015 um 17:46 schrieb Eric Blake:
>>>>>> On 08/24/2015 03:17 AM, Peter Lieven wrote:
>>>>>> this patch adds a probe that lists all enforceable and migrateable
>>>>>> CPU models to the -cpu help output. The idea is to know a priory
>>>>>> which CPU modules can be exposed to the user without loosing any
>>>>>> feature flags.
>>>>>> 
>>>>>> Signed-off-by: Peter Lieven <pl@kamp.de>
>>>>>> ---
>>>>>> target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 49 insertions(+)
>>>>> Is this same sort of listing available through QMP? Parsing '-cpu help'
>>>>> output is undesirable from libvirt point of view.
>>>>> 
>>>> A good point. But is there a QMP command to list available CPU types?
>>>> In this case it should be easy to extend.
>>> Yes, that's query-cpu-definitions. See past discussion at:
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/332554
>>> 
>>> Some of the assumptions at that thread changed. See:
>>> http://thread.gmane.org/gmane.comp.emulators.qemu/342582/focus=346651
>>> That means runnability should depend only on the accelerator type, and
>>> not on the machine-type anymore.
>> 
>> Thanks for the pointer. But is it possible to query cpu definitions without
>> a running Qemu? Like passing a QMP command on the commandline and
>> receive the answer on stdout?
> 
> Well, it's impossible to check if a CPU model is runnable without running QEMU.
> :)
> 
> I don't think you can send a QMP command through command-line arguments, but
> you can easily start a QMP monitor on stdin/stdio.
> 
> Example:
>  $ (echo '{ "execute": "qmp_capabilities" }';echo '{"execute":"query-cpu-definitions"}';echo '{"execute":"quit"}';) | ./x86_64-softmmu/qemu-system-x86_64 -nodefaults -S -qmp stdio -machine none -nographic
>  {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
>  {"return": {}}
>  {"return": [{"name": "Opteron_G5"}, {"name": "Opteron_G4"}, {"name": "Opteron_G3"}, {"name": "Opteron_G2"}, {"name": "Opteron_G1"}, {"name": "Broadwell"}, {"name": "Broadwell-noTSX"}, {"name": "Haswell"}, {"name": "Haswell-noTSX"}, {"name": "IvyBridge"}, {"name": "SandyBridge"}, {"name": "Westmere"}, {"name": "Nehalem"}, {"name": "Penryn"}, {"name": "Conroe"}, {"name": "n270"}, {"name": "athlon"}, {"name": "pentium3"}, {"name": "pentium2"}, {"name": "pentium"}, {"name": "486"}, {"name": "coreduo"}, {"name": "kvm32"}, {"name": "qemu32"}, {"name": "kvm64"}, {"name": "core2duo"}, {"name": "phenom"}, {"name": "qemu64"}]}
>  {"return": {}}
>  {"timestamp": {"seconds": 1440615228, "microseconds": 854114}, "event": "SHUTDOWN"}
>  $ 
> 


ok, now I have a list of cpu models.
what I could do now  is fire up a qemu process for each model with enforce and look at the exit code to see if it is enforcable on my host.

for me this would work as well.

or add a qmp command that lists all enforcable models.

Thanks for your help.
Peter


> 
>> 
>>> 
>>>> But, I wonder how to issue a QMP command before the vserver is actually
>>>> running? Is there a common way to do it?
>>> What's a vserver?
>>> 
>> 
>> A Virtual Server.
> 
> You mean the virtual machine? Yes, it is possible to run QMP commands before
> the machine is running (you just need to use -S). You can also use "-machine
> none" if you don't want any machine-specific initialization code to run at all.
> 
> -- 
> Eduardo

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Andreas Färber]

Hi,

Am 24.08.2015 um 03:17 schrieb Peter Lieven:
> this patch adds a probe that lists all enforceable and migrateable
> CPU models to the -cpu help output. The idea is to know a priory
> which CPU modules can be exposed to the user without loosing any

models

> feature flags.
> 
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---
>  target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index cfb8aa7..3a56d3f 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
[...]
> @@ -1987,6 +2026,16 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
>          listflags(f, cpu_fprintf, fw->feat_names);
>          (*cpu_fprintf)(f, "\n");
>      }
> +
> +    (*cpu_fprintf)(f, "\nEnforceable and migratable x86 CPU models in KVM mode:\n");
> +    (*cpu_fprintf)(f, " ");
> +    for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
> +        def = &builtin_x86_defs[i];
> +        if (x86_cpu_enforce_and_migratable(def)) {
> +            (*cpu_fprintf)(f, " %s", def->name);
> +        }
> +    }
> +    (*cpu_fprintf)(f, "\n");
>  }
>  
>  CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)

I don't think adding a new section is such a good idea here, it may add
more confusion than it helps. I would rather suggest to add some
annotation to the existing list.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

> Am 24.08.2015 um 22:22 schrieb Andreas Färber <afaerber@suse.de>:
> 
> Hi,
> 
>> Am 24.08.2015 um 03:17 schrieb Peter Lieven:
>> this patch adds a probe that lists all enforceable and migrateable
>> CPU models to the -cpu help output. The idea is to know a priory
>> which CPU modules can be exposed to the user without loosing any
> 
> models
> 
>> feature flags.
>> 
>> Signed-off-by: Peter Lieven <pl@kamp.de>
>> ---
>> target-i386/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 49 insertions(+)
>> 
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index cfb8aa7..3a56d3f 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
> [...]
>> @@ -1987,6 +2026,16 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf)
>>         listflags(f, cpu_fprintf, fw->feat_names);
>>         (*cpu_fprintf)(f, "\n");
>>     }
>> +
>> +    (*cpu_fprintf)(f, "\nEnforceable and migratable x86 CPU models in KVM mode:\n");
>> +    (*cpu_fprintf)(f, " ");
>> +    for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) {
>> +        def = &builtin_x86_defs[i];
>> +        if (x86_cpu_enforce_and_migratable(def)) {
>> +            (*cpu_fprintf)(f, " %s", def->name);
>> +        }
>> +    }
>> +    (*cpu_fprintf)(f, "\n");
>> }
>> 
>> CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
> 
> I don't think adding a new section is such a good idea here, it may add
> more confusion than it helps. I would rather suggest to add some
> annotation to the existing list.

I have also thought of this first, but found it confusing as well. But maybe you have a good idea how to format it?

I also think of Erics concern that it might be a good idea to get a json output of supported models somehow.

Peter

> 
> Regards,
> Andreas
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Eduardo Habkost]

On Mon, Aug 24, 2015 at 11:17:04AM +0200, Peter Lieven wrote:
> this patch adds a probe that lists all enforceable and migrateable
> CPU models to the -cpu help output. The idea is to know a priory
> which CPU modules can be exposed to the user without loosing any
> feature flags.
> 
> Signed-off-by: Peter Lieven <pl@kamp.de>
[...]
> +/*
> + * Check if the CPU Definition is enforcable on the current host CPU
> + * and contains no unmigratable flags.
> + *
> + * Returns: true if the CPU can be enforced and migrated.
> + */
> +static bool x86_cpu_enforce_and_migratable(X86CPUDefinition *def)
> +{
> +    int i;
> +    for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) {
> +        FeatureWordInfo *fw = &feature_word_info[i];
> +        uint32_t eax, ebx, ecx, edx, host;
> +        host_cpuid(fw->cpuid_eax, 0, &eax, &ebx, &ecx, &edx);

This isn't how you check if the CPU model can run in "enforce" mode.
Please read x86_cpu_filter_features().

Also, you can't tell if a CPU model is runnable in enforce mode unless
you know what's the accelerator being used (see
x86_cpu_filter_features()). How do you suggest we show
accelerator-specific information in help output?

-- 
Eduardo

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Peter Lieven]

Am 26.08.2015 um 17:54 schrieb Eduardo Habkost:
> On Mon, Aug 24, 2015 at 11:17:04AM +0200, Peter Lieven wrote:
>> this patch adds a probe that lists all enforceable and migrateable
>> CPU models to the -cpu help output. The idea is to know a priory
>> which CPU modules can be exposed to the user without loosing any
>> feature flags.
>>
>> Signed-off-by: Peter Lieven <pl@kamp.de>
> [...]
>> +/*
>> + * Check if the CPU Definition is enforcable on the current host CPU
>> + * and contains no unmigratable flags.
>> + *
>> + * Returns: true if the CPU can be enforced and migrated.
>> + */
>> +static bool x86_cpu_enforce_and_migratable(X86CPUDefinition *def)
>> +{
>> +    int i;
>> +    for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) {
>> +        FeatureWordInfo *fw = &feature_word_info[i];
>> +        uint32_t eax, ebx, ecx, edx, host;
>> +        host_cpuid(fw->cpuid_eax, 0, &eax, &ebx, &ecx, &edx);
> This isn't how you check if the CPU model can run in "enforce" mode.
> Please read x86_cpu_filter_features().

I did, but will do again. The problem is that x86_cpu_filter_features
requires enabled KVM to run. I believed internally it does something
similar to what I do here.

>
> Also, you can't tell if a CPU model is runnable in enforce mode unless
> you know what's the accelerator being used (see
> x86_cpu_filter_features()). How do you suggest we show
> accelerator-specific information in help output?
>

The subject was missing that the goal was to list enforceable models
in KVM mode. The output of the help page mentions this.

Andreas suggested to make annotations to the list of CPU models.
In theory it would be possible to have different annotations for different
accelerators.

Peter

Re: [Qemu-devel] [PATCH] target-i386: add a list of enforceable CPU models to the help output

[Eduardo Habkost]

On Wed, Aug 26, 2015 at 08:38:35PM +0200, Peter Lieven wrote:
> Am 26.08.2015 um 17:54 schrieb Eduardo Habkost:
> > On Mon, Aug 24, 2015 at 11:17:04AM +0200, Peter Lieven wrote:
> >> this patch adds a probe that lists all enforceable and migrateable
> >> CPU models to the -cpu help output. The idea is to know a priory
> >> which CPU modules can be exposed to the user without loosing any
> >> feature flags.
> >>
> >> Signed-off-by: Peter Lieven <pl@kamp.de>
> > [...]
> >> +/*
> >> + * Check if the CPU Definition is enforcable on the current host CPU
> >> + * and contains no unmigratable flags.
> >> + *
> >> + * Returns: true if the CPU can be enforced and migrated.
> >> + */
> >> +static bool x86_cpu_enforce_and_migratable(X86CPUDefinition *def)
> >> +{
> >> +    int i;
> >> +    for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) {
> >> +        FeatureWordInfo *fw = &feature_word_info[i];
> >> +        uint32_t eax, ebx, ecx, edx, host;
> >> +        host_cpuid(fw->cpuid_eax, 0, &eax, &ebx, &ecx, &edx);
> > This isn't how you check if the CPU model can run in "enforce" mode.
> > Please read x86_cpu_filter_features().
> 
> I did, but will do again. The problem is that x86_cpu_filter_features
> requires enabled KVM to run.

You don't have any choice: you need to initialize KVM to be able to
report correct results.

See this:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/133288
and the rest of the "s390x cpu model implementation" threads for some
information about accel object creation, and what's needed.

> I believed internally it does something
> similar to what I do here.

It doesn't. Please read the code.

> 
> >
> > Also, you can't tell if a CPU model is runnable in enforce mode unless
> > you know what's the accelerator being used (see
> > x86_cpu_filter_features()). How do you suggest we show
> > accelerator-specific information in help output?
> >
> 
> The subject was missing that the goal was to list enforceable models
> in KVM mode. The output of the help page mentions this.

There are zero mentions to KVM in x86_cpu_enforce_and_migratable(). If
the code is KVM-specific, please name functions and comment the code
accordingly.

> 
> Andreas suggested to make annotations to the list of CPU models.
> In theory it would be possible to have different annotations for different
> accelerators.

That's one possible way to implement it, but maybe there's no need to
make the code more complex for that. We can't check if the CPU model is
runnable at class_init time, anyway, and re-running the
runnability-check code in case the query is made multiple times won't be
be a problem.

-- 
Eduardo