| Message ID | 1440407824-30037-1-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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.
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
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
> 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)
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?
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?
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
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
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.
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.
> 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
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)
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(+)