| Message ID | 20170116195452.23532-1-ehabkost@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > Change the meaning of "-cpu host" to "enable all features > supported by the accelerator in the current host", so that it can > be used to enable/query all features supported by TCG. > > To make sure "host" is still at the end of the list in "-cpu > help", add a "ordering" field that will be used when sorting the > CPU model list. > > Cc: Richard Henderson <rth@twiddle.net> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > --- > target/i386/cpu-qom.h | 4 ++-- > target/i386/cpu.c | 26 +++++--------------------- > 2 files changed, 7 insertions(+), 23 deletions(-) > > diff --git a/target/i386/cpu-qom.h b/target/i386/cpu-qom.h > index 8cd607e9a2..75618919e3 100644 > --- a/target/i386/cpu-qom.h > +++ b/target/i386/cpu-qom.h > @@ -47,7 +47,7 @@ typedef struct X86CPUDefinition X86CPUDefinition; > /** > * X86CPUClass: > * @cpu_def: CPU model definition > - * @kvm_required: Whether CPU model requires KVM to be enabled. > + * @ordering: Ordering on the "-cpu help" CPU model list. > * @migration_safe: See CpuDefinitionInfo::migration_safe > * @parent_realize: The parent class' realize handler. > * @parent_reset: The parent class' reset handler. > @@ -62,7 +62,7 @@ typedef struct X86CPUClass { > /* Should be eventually replaced by subclass-specific property defaults. */ > X86CPUDefinition *cpu_def; > > - bool kvm_required; > + int ordering; > bool migration_safe; > > /* Optional description of CPU model. > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index ec6eaf215c..e0ca8c0288 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -1549,7 +1549,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) > X86CPUClass *xcc = X86_CPU_CLASS(oc); > uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0; > > - xcc->kvm_required = true; > + xcc->ordering = 9; /* Show it last on "-cpu help" */ > > host_cpuid(0x0, 0, &eax, &ebx, &ecx, &edx); > x86_cpu_vendor_words2str(host_cpudef.vendor, ebx, edx, ecx); > @@ -1563,8 +1563,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) > > xcc->cpu_def = &host_cpudef; > xcc->model_description = > - "KVM processor with all supported host features " > - "(only available in KVM mode)"; > + "Enables all features supported by the accelerator in the current host"; > > /* level, xlevel, xlevel2, and the feature words are initialized on > * instance_init, because they require KVM to be initialized. > @@ -2075,13 +2074,6 @@ static void x86_cpu_class_check_missing_features(X86CPUClass *xcc, > Error *err = NULL; > strList **next = missing_feats; > > - if (xcc->kvm_required && !kvm_enabled()) { > - strList *new = g_new0(strList, 1); > - new->value = g_strdup("kvm");; > - *missing_feats = new; > - return; > - } > - > xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc)))); > > x86_cpu_load_features(xc, &err); > @@ -2129,7 +2121,7 @@ static void listflags(FILE *f, fprintf_function print, const char **featureset) > } > } > > -/* Sort alphabetically by type name, listing kvm_required models last. */ > +/* Sort alphabetically by type name, respecting X86CPUClass::ordering. */ > static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) > { > ObjectClass *class_a = (ObjectClass *)a; > @@ -2138,9 +2130,8 @@ static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) > X86CPUClass *cc_b = X86_CPU_CLASS(class_b); > const char *name_a, *name_b; > > - if (cc_a->kvm_required != cc_b->kvm_required) { > - /* kvm_required items go last */ > - return cc_a->kvm_required ? 1 : -1; > + if (cc_a->ordering != cc_b->ordering) { > + return cc_a->ordering - cc_b->ordering; > } else { > name_a = object_class_get_name(class_a); > name_b = object_class_get_name(class_b); > @@ -3191,13 +3182,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) > Error *local_err = NULL; > static bool ht_warned; > > - if (xcc->kvm_required && !kvm_enabled()) { > - char *name = x86_cpu_class_get_model_name(xcc); > - error_setg(&local_err, "CPU model '%s' requires KVM", name); > - g_free(name); > - goto out; > - } > - > if (cpu->apic_id == UNASSIGNED_APIC_ID) { > error_setg(errp, "apic-id property was not initialized properly"); > return; FYI libvirt will also need changing. Currently it reports: Original error from libvirt: unsupported configuration: CPU mode 'host-passthrough' for x86_64 qemu domain on x86_64 host is not supported by hypervisor [code=67 int1=-1] Rich.
On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > Change the meaning of "-cpu host" to "enable all features > supported by the accelerator in the current host", so that it can > be used to enable/query all features supported by TCG. > > To make sure "host" is still at the end of the list in "-cpu > help", add a "ordering" field that will be used when sorting the > CPU model list. As far as I can tell from light testing, the patch itself works as advertized. However a current Fedora debug kernel seems to have a lot of problems booting on the TCG + -cpu host machine. See the attached debug messages. I'll try it with a non-debug kernel shortly. Rich.
On Tue, Jan 17, 2017 at 01:42:08PM +0000, Richard W.M. Jones wrote: > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > > Change the meaning of "-cpu host" to "enable all features > > supported by the accelerator in the current host", so that it can > > be used to enable/query all features supported by TCG. > > > > To make sure "host" is still at the end of the list in "-cpu > > help", add a "ordering" field that will be used when sorting the > > CPU model list. > > As far as I can tell from light testing, the patch itself works > as advertized. > > However a current Fedora debug kernel seems to have a lot of problems > booting on the TCG + -cpu host machine. See the attached debug > messages. > > I'll try it with a non-debug kernel shortly. With the non-debug kernel, the error is (probably?) the same one. At least, the crash appears in roughly the same place. Are you planning to extend this work to other architectures than x86? Rich.
Oh no wait, these errors are just because of the new version of qemu that I am using to test your patch, so nothing to do with this patch. /me fires up git bisect ... Rich.
On Tue, Jan 17, 2017 at 01:39:14PM +0000, Richard W.M. Jones wrote: > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > > Change the meaning of "-cpu host" to "enable all features > > supported by the accelerator in the current host", so that it can > > be used to enable/query all features supported by TCG. > > > > To make sure "host" is still at the end of the list in "-cpu > > help", add a "ordering" field that will be used when sorting the > > CPU model list. > > > > Cc: Richard Henderson <rth@twiddle.net> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > > --- > > target/i386/cpu-qom.h | 4 ++-- > > target/i386/cpu.c | 26 +++++--------------------- > > 2 files changed, 7 insertions(+), 23 deletions(-) > > > > diff --git a/target/i386/cpu-qom.h b/target/i386/cpu-qom.h > > index 8cd607e9a2..75618919e3 100644 > > --- a/target/i386/cpu-qom.h > > +++ b/target/i386/cpu-qom.h > > @@ -47,7 +47,7 @@ typedef struct X86CPUDefinition X86CPUDefinition; > > /** > > * X86CPUClass: > > * @cpu_def: CPU model definition > > - * @kvm_required: Whether CPU model requires KVM to be enabled. > > + * @ordering: Ordering on the "-cpu help" CPU model list. > > * @migration_safe: See CpuDefinitionInfo::migration_safe > > * @parent_realize: The parent class' realize handler. > > * @parent_reset: The parent class' reset handler. > > @@ -62,7 +62,7 @@ typedef struct X86CPUClass { > > /* Should be eventually replaced by subclass-specific property defaults. */ > > X86CPUDefinition *cpu_def; > > > > - bool kvm_required; > > + int ordering; > > bool migration_safe; > > > > /* Optional description of CPU model. > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > > index ec6eaf215c..e0ca8c0288 100644 > > --- a/target/i386/cpu.c > > +++ b/target/i386/cpu.c > > @@ -1549,7 +1549,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) > > X86CPUClass *xcc = X86_CPU_CLASS(oc); > > uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0; > > > > - xcc->kvm_required = true; > > + xcc->ordering = 9; /* Show it last on "-cpu help" */ > > > > host_cpuid(0x0, 0, &eax, &ebx, &ecx, &edx); > > x86_cpu_vendor_words2str(host_cpudef.vendor, ebx, edx, ecx); > > @@ -1563,8 +1563,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) > > > > xcc->cpu_def = &host_cpudef; > > xcc->model_description = > > - "KVM processor with all supported host features " > > - "(only available in KVM mode)"; > > + "Enables all features supported by the accelerator in the current host"; > > > > /* level, xlevel, xlevel2, and the feature words are initialized on > > * instance_init, because they require KVM to be initialized. > > @@ -2075,13 +2074,6 @@ static void x86_cpu_class_check_missing_features(X86CPUClass *xcc, > > Error *err = NULL; > > strList **next = missing_feats; > > > > - if (xcc->kvm_required && !kvm_enabled()) { > > - strList *new = g_new0(strList, 1); > > - new->value = g_strdup("kvm");; > > - *missing_feats = new; > > - return; > > - } > > - > > xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc)))); > > > > x86_cpu_load_features(xc, &err); > > @@ -2129,7 +2121,7 @@ static void listflags(FILE *f, fprintf_function print, const char **featureset) > > } > > } > > > > -/* Sort alphabetically by type name, listing kvm_required models last. */ > > +/* Sort alphabetically by type name, respecting X86CPUClass::ordering. */ > > static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) > > { > > ObjectClass *class_a = (ObjectClass *)a; > > @@ -2138,9 +2130,8 @@ static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) > > X86CPUClass *cc_b = X86_CPU_CLASS(class_b); > > const char *name_a, *name_b; > > > > - if (cc_a->kvm_required != cc_b->kvm_required) { > > - /* kvm_required items go last */ > > - return cc_a->kvm_required ? 1 : -1; > > + if (cc_a->ordering != cc_b->ordering) { > > + return cc_a->ordering - cc_b->ordering; > > } else { > > name_a = object_class_get_name(class_a); > > name_b = object_class_get_name(class_b); > > @@ -3191,13 +3182,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) > > Error *local_err = NULL; > > static bool ht_warned; > > > > - if (xcc->kvm_required && !kvm_enabled()) { > > - char *name = x86_cpu_class_get_model_name(xcc); > > - error_setg(&local_err, "CPU model '%s' requires KVM", name); > > - g_free(name); > > - goto out; > > - } > > - > > if (cpu->apic_id == UNASSIGNED_APIC_ID) { > > error_setg(errp, "apic-id property was not initialized properly"); > > return; > > FYI libvirt will also need changing. Currently it reports: > > Original error from libvirt: unsupported configuration: CPU mode 'host-passthrough' for x86_64 qemu domain on x86_64 host is not supported by hypervisor [code=67 int1=-1] > I'm not sure libvirt should translate "host-passthrough" to "-cpu host" with TCG. The documented semantics of "host-passthrough" are probably more specific, and may not make sense for TCG.
On Tue, Jan 17, 2017 at 01:57:34PM +0000, Richard W.M. Jones wrote: > > Oh no wait, these errors are just because of the new version of qemu > that I am using to test your patch, so nothing to do with this patch. > > /me fires up git bisect ... Probably it's the bug I have bisected and reported yesterday. See: Subject: [Qemu-devel] [PATCH 49/65] tcg/i386: Rely on undefined/undocumented behaviour of BSF/BSR
On Tue, Jan 17, 2017 at 12:05:41PM -0200, Eduardo Habkost wrote: > On Tue, Jan 17, 2017 at 01:57:34PM +0000, Richard W.M. Jones wrote: > > > > Oh no wait, these errors are just because of the new version of qemu > > that I am using to test your patch, so nothing to do with this patch. > > > > /me fires up git bisect ... > > Probably it's the bug I have bisected and reported yesterday. > See: > > Subject: [Qemu-devel] [PATCH 49/65] tcg/i386: Rely on undefined/undocumented behaviour of BSF/BSR Yup, you're way ahead of me. Reverting that commit (4ac76910734209) does indeed fix Fedora kernel + TCG. Please add: Tested-by: Richard W.M. Jones <rjones@redhat.com> to the current patch (``i386: Support "-cpu host" on TCG too'') if you wish, and CC me on any future versions so I can test those as well. Thanks, Rich.
On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > Change the meaning of "-cpu host" to "enable all features > supported by the accelerator in the current host", so that it can > be used to enable/query all features supported by TCG. > > To make sure "host" is still at the end of the list in "-cpu > help", add a "ordering" field that will be used when sorting the > CPU model list. To be clear, "-cpu host" for TCG is not talking about the actual host OS feature support, right ? x86_64 TCG can be run on a ppc host, so presumably "-cpu host" just means "all features that this TCG binary is able to emulate" ? This feels like it is introducing scope for confusion vs KVM -cpu host, so I wonder if different naming is better for this. Regards, Daniel
On 19 January 2017 at 17:50, Daniel P. Berrange <berrange@redhat.com> wrote: > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: >> Change the meaning of "-cpu host" to "enable all features >> supported by the accelerator in the current host", so that it can >> be used to enable/query all features supported by TCG. >> >> To make sure "host" is still at the end of the list in "-cpu >> help", add a "ordering" field that will be used when sorting the >> CPU model list. > > To be clear, "-cpu host" for TCG is not talking about the actual > host OS feature support, right ? x86_64 TCG can be run on a ppc host, > so presumably "-cpu host" just means "all features that this TCG binary > is able to emulate" ? > > This feels like it is introducing scope for confusion vs KVM -cpu host, > so I wonder if different naming is better for this. The idea is that you do want an option that works whatever the accelerator is, though, so as a user you don't need to worry about messing with the command line for KVM vs TCG vs "try KVM and fall back to TCG". (I think "-cpu best" has been thrown about as a suggestion for this before.) thanks -- PMM
On Thu, Jan 19, 2017 at 06:22:40PM +0000, Peter Maydell wrote: > On 19 January 2017 at 17:50, Daniel P. Berrange <berrange@redhat.com> wrote: > > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > >> Change the meaning of "-cpu host" to "enable all features > >> supported by the accelerator in the current host", so that it can > >> be used to enable/query all features supported by TCG. > >> > >> To make sure "host" is still at the end of the list in "-cpu > >> help", add a "ordering" field that will be used when sorting the > >> CPU model list. > > > > To be clear, "-cpu host" for TCG is not talking about the actual > > host OS feature support, right ? x86_64 TCG can be run on a ppc host, > > so presumably "-cpu host" just means "all features that this TCG binary > > is able to emulate" ? > > > > This feels like it is introducing scope for confusion vs KVM -cpu host, > > so I wonder if different naming is better for this. > > The idea is that you do want an option that works whatever the > accelerator is, though, so as a user you don't need to worry > about messing with the command line for KVM vs TCG vs "try > KVM and fall back to TCG". (I think "-cpu best" has been thrown about > as a suggestion for this before.) "-cpu best" has been proposed with different semantics before: one meant "select the the best CPU model from the builtin table", and another that's equivalent to the meaning of "host" in this patch. s390x uses "max CPU model" internally to represent a CPU model that has all supported features enabled. If "-cpu host" is not a good name, I suggest "-cpu max".
On Thu, Jan 19, 2017 at 04:31:45PM -0200, Eduardo Habkost wrote: > On Thu, Jan 19, 2017 at 06:22:40PM +0000, Peter Maydell wrote: > > On 19 January 2017 at 17:50, Daniel P. Berrange <berrange@redhat.com> wrote: > > > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > > >> Change the meaning of "-cpu host" to "enable all features > > >> supported by the accelerator in the current host", so that it can > > >> be used to enable/query all features supported by TCG. > > >> > > >> To make sure "host" is still at the end of the list in "-cpu > > >> help", add a "ordering" field that will be used when sorting the > > >> CPU model list. > > > > > > To be clear, "-cpu host" for TCG is not talking about the actual > > > host OS feature support, right ? x86_64 TCG can be run on a ppc host, > > > so presumably "-cpu host" just means "all features that this TCG binary > > > is able to emulate" ? > > > > > > This feels like it is introducing scope for confusion vs KVM -cpu host, > > > so I wonder if different naming is better for this. > > > > The idea is that you do want an option that works whatever the > > accelerator is, though, so as a user you don't need to worry > > about messing with the command line for KVM vs TCG vs "try > > KVM and fall back to TCG". (I think "-cpu best" has been thrown about > > as a suggestion for this before.) > > "-cpu best" has been proposed with different semantics before: > one meant "select the the best CPU model from the builtin table", > and another that's equivalent to the meaning of "host" in this > patch. > > s390x uses "max CPU model" internally to represent a CPU model > that has all supported features enabled. > > If "-cpu host" is not a good name, I suggest "-cpu max". Yeah, I think "-cpu max" better describes the intended semantics for this with TCG. I guess for KVM -cpu host & -cpu max would be equivalent. Regards, Daniel
On Thu, Jan 19, 2017 at 06:38:36PM +0000, Daniel P. Berrange wrote: > On Thu, Jan 19, 2017 at 04:31:45PM -0200, Eduardo Habkost wrote: > > On Thu, Jan 19, 2017 at 06:22:40PM +0000, Peter Maydell wrote: > > > On 19 January 2017 at 17:50, Daniel P. Berrange <berrange@redhat.com> wrote: > > > > On Mon, Jan 16, 2017 at 05:54:52PM -0200, Eduardo Habkost wrote: > > > >> Change the meaning of "-cpu host" to "enable all features > > > >> supported by the accelerator in the current host", so that it can > > > >> be used to enable/query all features supported by TCG. > > > >> > > > >> To make sure "host" is still at the end of the list in "-cpu > > > >> help", add a "ordering" field that will be used when sorting the > > > >> CPU model list. > > > > > > > > To be clear, "-cpu host" for TCG is not talking about the actual > > > > host OS feature support, right ? x86_64 TCG can be run on a ppc host, > > > > so presumably "-cpu host" just means "all features that this TCG binary > > > > is able to emulate" ? > > > > > > > > This feels like it is introducing scope for confusion vs KVM -cpu host, > > > > so I wonder if different naming is better for this. > > > > > > The idea is that you do want an option that works whatever the > > > accelerator is, though, so as a user you don't need to worry > > > about messing with the command line for KVM vs TCG vs "try > > > KVM and fall back to TCG". (I think "-cpu best" has been thrown about > > > as a suggestion for this before.) > > > > "-cpu best" has been proposed with different semantics before: > > one meant "select the the best CPU model from the builtin table", > > and another that's equivalent to the meaning of "host" in this > > patch. > > > > s390x uses "max CPU model" internally to represent a CPU model > > that has all supported features enabled. > > > > If "-cpu host" is not a good name, I suggest "-cpu max". > > Yeah, I think "-cpu max" better describes the intended semantics for this > with TCG. I guess for KVM -cpu host & -cpu max would be equivalent. Agreed. I will send v2 with "-cpu max".
diff --git a/target/i386/cpu-qom.h b/target/i386/cpu-qom.h index 8cd607e9a2..75618919e3 100644 --- a/target/i386/cpu-qom.h +++ b/target/i386/cpu-qom.h @@ -47,7 +47,7 @@ typedef struct X86CPUDefinition X86CPUDefinition; /** * X86CPUClass: * @cpu_def: CPU model definition - * @kvm_required: Whether CPU model requires KVM to be enabled. + * @ordering: Ordering on the "-cpu help" CPU model list. * @migration_safe: See CpuDefinitionInfo::migration_safe * @parent_realize: The parent class' realize handler. * @parent_reset: The parent class' reset handler. @@ -62,7 +62,7 @@ typedef struct X86CPUClass { /* Should be eventually replaced by subclass-specific property defaults. */ X86CPUDefinition *cpu_def; - bool kvm_required; + int ordering; bool migration_safe; /* Optional description of CPU model. diff --git a/target/i386/cpu.c b/target/i386/cpu.c index ec6eaf215c..e0ca8c0288 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -1549,7 +1549,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) X86CPUClass *xcc = X86_CPU_CLASS(oc); uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0; - xcc->kvm_required = true; + xcc->ordering = 9; /* Show it last on "-cpu help" */ host_cpuid(0x0, 0, &eax, &ebx, &ecx, &edx); x86_cpu_vendor_words2str(host_cpudef.vendor, ebx, edx, ecx); @@ -1563,8 +1563,7 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) xcc->cpu_def = &host_cpudef; xcc->model_description = - "KVM processor with all supported host features " - "(only available in KVM mode)"; + "Enables all features supported by the accelerator in the current host"; /* level, xlevel, xlevel2, and the feature words are initialized on * instance_init, because they require KVM to be initialized. @@ -2075,13 +2074,6 @@ static void x86_cpu_class_check_missing_features(X86CPUClass *xcc, Error *err = NULL; strList **next = missing_feats; - if (xcc->kvm_required && !kvm_enabled()) { - strList *new = g_new0(strList, 1); - new->value = g_strdup("kvm");; - *missing_feats = new; - return; - } - xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc)))); x86_cpu_load_features(xc, &err); @@ -2129,7 +2121,7 @@ static void listflags(FILE *f, fprintf_function print, const char **featureset) } } -/* Sort alphabetically by type name, listing kvm_required models last. */ +/* Sort alphabetically by type name, respecting X86CPUClass::ordering. */ static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) { ObjectClass *class_a = (ObjectClass *)a; @@ -2138,9 +2130,8 @@ static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) X86CPUClass *cc_b = X86_CPU_CLASS(class_b); const char *name_a, *name_b; - if (cc_a->kvm_required != cc_b->kvm_required) { - /* kvm_required items go last */ - return cc_a->kvm_required ? 1 : -1; + if (cc_a->ordering != cc_b->ordering) { + return cc_a->ordering - cc_b->ordering; } else { name_a = object_class_get_name(class_a); name_b = object_class_get_name(class_b); @@ -3191,13 +3182,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) Error *local_err = NULL; static bool ht_warned; - if (xcc->kvm_required && !kvm_enabled()) { - char *name = x86_cpu_class_get_model_name(xcc); - error_setg(&local_err, "CPU model '%s' requires KVM", name); - g_free(name); - goto out; - } - if (cpu->apic_id == UNASSIGNED_APIC_ID) { error_setg(errp, "apic-id property was not initialized properly"); return;
Change the meaning of "-cpu host" to "enable all features supported by the accelerator in the current host", so that it can be used to enable/query all features supported by TCG. To make sure "host" is still at the end of the list in "-cpu help", add a "ordering" field that will be used when sorting the CPU model list. Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- target/i386/cpu-qom.h | 4 ++-- target/i386/cpu.c | 26 +++++--------------------- 2 files changed, 7 insertions(+), 23 deletions(-)