| Message ID | 1354645978-17362-1-git-send-email-ehabkost@redhat.com |
|---|---|
| State | New |
| Headers | show |
Am 04.12.2012 19:32, schrieb Eduardo Habkost: > The external CPU models were removed on QEMU 1.2, and the support for > the "cpudef" config sections was documented as deprecated, but the > actual removal of the config section was pending. > > Now that QEMU 1.3 was released, we can finally kill the support for > cpudef config sections, and support only the built-in CPU models from > target-i386/cpu.c. > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> This looks okay so far, but I'm guessing this was based on another branch of yours? If we apply this right now, we would also want to remove the #ifdef'ed cpudef_init() or so function invoking the parsing, no? Andreas > --- > qemu-config.c | 49 ------------------------------------------------- > 1 file changed, 49 deletions(-) > > diff --git a/qemu-config.c b/qemu-config.c > index 10d1ba4..aa78fb9 100644 > --- a/qemu-config.c > +++ b/qemu-config.c > @@ -417,54 +417,6 @@ static QemuOptsList qemu_trace_opts = { > }, > }; > > -static QemuOptsList qemu_cpudef_opts = { > - .name = "cpudef", > - .head = QTAILQ_HEAD_INITIALIZER(qemu_cpudef_opts.head), > - .desc = { > - { > - .name = "name", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "level", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "vendor", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "family", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "model", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "stepping", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "feature_edx", /* cpuid 0000_0001.edx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "feature_ecx", /* cpuid 0000_0001.ecx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "extfeature_edx", /* cpuid 8000_0001.edx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "extfeature_ecx", /* cpuid 8000_0001.ecx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "xlevel", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "model_id", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "vendor_override", > - .type = QEMU_OPT_NUMBER, > - }, > - { /* end of list */ } > - }, > -}; > - > QemuOptsList qemu_spice_opts = { > .name = "spice", > .head = QTAILQ_HEAD_INITIALIZER(qemu_spice_opts.head), > @@ -700,7 +652,6 @@ static QemuOptsList *vm_config_groups[32] = { > &qemu_rtc_opts, > &qemu_global_opts, > &qemu_mon_opts, > - &qemu_cpudef_opts, > &qemu_trace_opts, > &qemu_option_rom_opts, > &qemu_machine_opts, >
On Tue, Dec 04, 2012 at 07:41:47PM +0100, Andreas Färber wrote: > Am 04.12.2012 19:32, schrieb Eduardo Habkost: > > The external CPU models were removed on QEMU 1.2, and the support for > > the "cpudef" config sections was documented as deprecated, but the > > actual removal of the config section was pending. > > > > Now that QEMU 1.3 was released, we can finally kill the support for > > cpudef config sections, and support only the built-in CPU models from > > target-i386/cpu.c. > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > > This looks okay so far, but I'm guessing this was based on another > branch of yours? If we apply this right now, we would also want to > remove the #ifdef'ed cpudef_init() or so function invoking the parsing, no? Right now cpudef_init() calls cpudef_setup(), that initializes some fields in the builtin CPU model list on x86, but doesn't use the cpudef config section anymore[1]. cpudef_setup() and cpudef_init() will be killed later, when we kill the builtin_x86_defs table and introduce CPU model subclasses. [1] The code dealing with the cpudef section was removed on c04321b3685a0b06d737d04146a0f1f2c5950b39. So, in the end it would be safe to apply this patch before 1.3, as the code that actually used the cpudef CPU models was already removed. > > Andreas > > > --- > > qemu-config.c | 49 ------------------------------------------------- > > 1 file changed, 49 deletions(-) > > > > diff --git a/qemu-config.c b/qemu-config.c > > index 10d1ba4..aa78fb9 100644 > > --- a/qemu-config.c > > +++ b/qemu-config.c > > @@ -417,54 +417,6 @@ static QemuOptsList qemu_trace_opts = { > > }, > > }; > > > > -static QemuOptsList qemu_cpudef_opts = { > > - .name = "cpudef", > > - .head = QTAILQ_HEAD_INITIALIZER(qemu_cpudef_opts.head), > > - .desc = { > > - { > > - .name = "name", > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "level", > > - .type = QEMU_OPT_NUMBER, > > - },{ > > - .name = "vendor", > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "family", > > - .type = QEMU_OPT_NUMBER, > > - },{ > > - .name = "model", > > - .type = QEMU_OPT_NUMBER, > > - },{ > > - .name = "stepping", > > - .type = QEMU_OPT_NUMBER, > > - },{ > > - .name = "feature_edx", /* cpuid 0000_0001.edx */ > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "feature_ecx", /* cpuid 0000_0001.ecx */ > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "extfeature_edx", /* cpuid 8000_0001.edx */ > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "extfeature_ecx", /* cpuid 8000_0001.ecx */ > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "xlevel", > > - .type = QEMU_OPT_NUMBER, > > - },{ > > - .name = "model_id", > > - .type = QEMU_OPT_STRING, > > - },{ > > - .name = "vendor_override", > > - .type = QEMU_OPT_NUMBER, > > - }, > > - { /* end of list */ } > > - }, > > -}; > > - > > QemuOptsList qemu_spice_opts = { > > .name = "spice", > > .head = QTAILQ_HEAD_INITIALIZER(qemu_spice_opts.head), > > @@ -700,7 +652,6 @@ static QemuOptsList *vm_config_groups[32] = { > > &qemu_rtc_opts, > > &qemu_global_opts, > > &qemu_mon_opts, > > - &qemu_cpudef_opts, > > &qemu_trace_opts, > > &qemu_option_rom_opts, > > &qemu_machine_opts, > > > > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
Thanks, applied. On Tue, Dec 4, 2012 at 6:32 PM, Eduardo Habkost <ehabkost@redhat.com> wrote: > The external CPU models were removed on QEMU 1.2, and the support for > the "cpudef" config sections was documented as deprecated, but the > actual removal of the config section was pending. > > Now that QEMU 1.3 was released, we can finally kill the support for > cpudef config sections, and support only the built-in CPU models from > target-i386/cpu.c. > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > --- > qemu-config.c | 49 ------------------------------------------------- > 1 file changed, 49 deletions(-) > > diff --git a/qemu-config.c b/qemu-config.c > index 10d1ba4..aa78fb9 100644 > --- a/qemu-config.c > +++ b/qemu-config.c > @@ -417,54 +417,6 @@ static QemuOptsList qemu_trace_opts = { > }, > }; > > -static QemuOptsList qemu_cpudef_opts = { > - .name = "cpudef", > - .head = QTAILQ_HEAD_INITIALIZER(qemu_cpudef_opts.head), > - .desc = { > - { > - .name = "name", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "level", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "vendor", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "family", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "model", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "stepping", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "feature_edx", /* cpuid 0000_0001.edx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "feature_ecx", /* cpuid 0000_0001.ecx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "extfeature_edx", /* cpuid 8000_0001.edx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "extfeature_ecx", /* cpuid 8000_0001.ecx */ > - .type = QEMU_OPT_STRING, > - },{ > - .name = "xlevel", > - .type = QEMU_OPT_NUMBER, > - },{ > - .name = "model_id", > - .type = QEMU_OPT_STRING, > - },{ > - .name = "vendor_override", > - .type = QEMU_OPT_NUMBER, > - }, > - { /* end of list */ } > - }, > -}; > - > QemuOptsList qemu_spice_opts = { > .name = "spice", > .head = QTAILQ_HEAD_INITIALIZER(qemu_spice_opts.head), > @@ -700,7 +652,6 @@ static QemuOptsList *vm_config_groups[32] = { > &qemu_rtc_opts, > &qemu_global_opts, > &qemu_mon_opts, > - &qemu_cpudef_opts, > &qemu_trace_opts, > &qemu_option_rom_opts, > &qemu_machine_opts, > -- > 1.7.11.7 > >
Am 08.12.2012 18:54, schrieb Blue Swirl:
> Thanks, applied.
As discussed this still leaves some cpudef cruft behind.
Eduardo, can you please send a follow-up to move the versioning code and
kills all cpudef_*(), now that the patch got prematurely applied?
Thanks,
Andreas
On Sat, Dec 8, 2012 at 6:02 PM, Andreas Färber <afaerber@suse.de> wrote: > Am 08.12.2012 18:54, schrieb Blue Swirl: >> Thanks, applied. > > As discussed this still leaves some cpudef cruft behind. But Eduardo said that it will be removed later. > Eduardo, can you please send a follow-up to move the versioning code and > kills all cpudef_*(), now that the patch got prematurely applied? > > Thanks, > Andreas > > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Am 08.12.2012 21:00, schrieb Blue Swirl: > On Sat, Dec 8, 2012 at 6:02 PM, Andreas Färber <afaerber@suse.de> wrote: >> Am 08.12.2012 18:54, schrieb Blue Swirl: >>> Thanks, applied. >> >> As discussed this still leaves some cpudef cruft behind. > > But Eduardo said that it will be removed later. I chose not to include it in the current qom-cpu pull while I was still investigating how to resolve the conflict between the patch claiming to "finally kill", not satisfactorily doing it but not yet having X86CPU subclasses. Actually I now found a very easy and un-intrusive way to clean that up, series coming up! What I am disappointed about here is the work duplication. The only user of this cpudef is the x86 CPU, an area that I have been maintaining since Anthony asked for help with his maintenance areas. You can argue that qemu-config.c is not under my maintenance and that target-i386/cpu.c is not properly documented as such in MAINTAINERS (which I will fix, noticing this), but either way since my reply indicates that I started review, I would have appreciated a reply indicating you agree with Eduardo I should apply it as such or asking whether you can apply it now rather than applying this patch without anyone's Reviewed-by or Acked-by while my pull is still in flight. Generally I expect committers to handle PULLs from maintainers and PATCHes from unmaintained areas only. At times in lack of communication those borders get blurred, leading to patches handled differently by two persons, such as the Haswell patch showing up twice in the shortlog or this patch getting applied while review comments are unresolved. If you think I'm doing a terrible job as maintainer (hard freeze, review times, my perfectionism...) and wish to handle x86 CPU patches yourself, just say so openly and I'll happily invest my time in an area where the effort is more appreciated. What I would've liked was an idea raised at QEMU Summit of having a staging tree similar to the trivial queue as sort-of a last-call to point out typos or potential conflicts between trees before a patch lands in qemu.git and either stays or must be reverted or followed up. But this did not find a lot of support. Regards, Andreas
Hello, This mini-series follows up the removal of cpudef config section support. It cleans up the list of x86 definitions previously parsed from the cpudefs and rips out everything cpudef_*, making remaining x86_cpudef_setup() static. This is done by calling our setup code from class_init - an alternative would be type registration time. As a bonus I'm proposing to document my coordinating the x86 CPU rework in the MAINTAINERS file. This series is based on my qom-cpu-next branch (pending qom-cpu + latest master) and is intended to be included in an upcoming qom-cpu pull, just to be clear. :) Regards, Andreas Cc: Blue Swirl <blauwirbel@gmail.com> Cc: Anthony Liguori <anthony@codemonkey.ws> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Andreas Färber (4): target-i386: Inline -cpu host check into cpu_x86_register() target-i386: Drop redundant list of CPU definitions Really finally kill cpudef config section support MAINTAINERS: Include X86CPU in CPU maintenance area MAINTAINERS | 1 + arch_init.c | 7 ------- arch_init.h | 1 - bsd-user/main.c | 3 --- linux-user/main.c | 3 --- target-i386/cpu.c | 54 ++++++++++++++++++++++++++--------------------------- target-i386/cpu.h | 2 -- vl.c | 7 ------- 8 Dateien geändert, 27 Zeilen hinzugefügt(+), 51 Zeilen entfernt(-)
On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <afaerber@suse.de> wrote: > Am 08.12.2012 21:00, schrieb Blue Swirl: >> On Sat, Dec 8, 2012 at 6:02 PM, Andreas Färber <afaerber@suse.de> wrote: >>> Am 08.12.2012 18:54, schrieb Blue Swirl: >>>> Thanks, applied. >>> >>> As discussed this still leaves some cpudef cruft behind. >> >> But Eduardo said that it will be removed later. > > I chose not to include it in the current qom-cpu pull while I was still > investigating how to resolve the conflict between the patch claiming to > "finally kill", not satisfactorily doing it but not yet having X86CPU > subclasses. > > Actually I now found a very easy and un-intrusive way to clean that up, > series coming up! > > What I am disappointed about here is the work duplication. The only user > of this cpudef is the x86 CPU, an area that I have been maintaining > since Anthony asked for help with his maintenance areas. You can argue > that qemu-config.c is not under my maintenance and that > target-i386/cpu.c is not properly documented as such in MAINTAINERS > (which I will fix, noticing this), but either way since my reply > indicates that I started review, I would have appreciated a reply > indicating you agree with Eduardo I should apply it as such or asking > whether you can apply it now rather than applying this patch without > anyone's Reviewed-by or Acked-by while my pull is still in flight. Actually I checked that it didn't conflict with your pull (which I applied) and also with your RFC series (which I didn't apply, of course). So it looked OK to me. > Generally I expect committers to handle PULLs from maintainers and > PATCHes from unmaintained areas only. At times in lack of communication > those borders get blurred, leading to patches handled differently by two > persons, such as the Haswell patch showing up twice in the shortlog or > this patch getting applied while review comments are unresolved. > > If you think I'm doing a terrible job as maintainer (hard freeze, review > times, my perfectionism...) and wish to handle x86 CPU patches yourself, > just say so openly and I'll happily invest my time in an area where the > effort is more appreciated. I think you are doing a great job, thanks for your efforts. I have no interest for doing the QOM conversion myself. > What I would've liked was an idea raised at QEMU Summit of having a > staging tree similar to the trivial queue as sort-of a last-call to > point out typos or potential conflicts between trees before a patch > lands in qemu.git and either stays or must be reverted or followed up. > But this did not find a lot of support. I think it would be nice if you could take patches like this which are close to your CPU patches and keep them in your tree, or just NAK patches which conflict with other work. That kind of coordination would avoid staging problems. What's for example the plan for Igor's series, should they be applied next or something else? > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Am 09.12.2012 21:46, schrieb Blue Swirl: > On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <afaerber@suse.de> wrote: >> [...] I would have appreciated a reply >> indicating you agree with Eduardo I should apply it as such or asking >> whether you can apply it now rather than applying this patch without >> anyone's Reviewed-by or Acked-by while my pull is still in flight. > > Actually I checked that it didn't conflict with your pull (which I > applied) and also with your RFC series (which I didn't apply, of > course). So it looked OK to me. Yes thanks, your merging the ioport pull was indeed appreciated (although it does push the merge conflict to Gerd's earlier ACPI pull). But actually I was referring to my qom-cpu pull. ;) It automatically rebases, too, so no drama. [snip] Thanks for your kind words. I was not trying to push QOM authoring work on you, just wondering about who applies which patches when. What I was looking for is some constructive feedback on what I should or shouldn't do to help clarify responsibilities: > I think it would be nice if you could take patches like this which are > close to your CPU patches and keep them in your tree, or just NAK > patches which conflict with other work. That kind of coordination > would avoid staging problems. I take it that adding an Acked-by to patches and sending a PULL later without sending a "Thanks applied" reply was not a good idea of mine, possibly confusing Anthony's mailbox script. Your response I'm interpreting as I should've replied that I'm investigating the enhancement instead of waiting until I have results to share of whether or not it can be done better in one go (and not as being some formal MAINTAINERS file pattern documentation issue). And my wait on the frozen qom-cpu branch was resolvable with a scripted double-rebase first on qom-cpu, then on master, to simulate a qom-cpu merge for the new follow-up series. > What's for example the plan for Igor's series, should they be applied > next or something else? I've been discussing our next steps with both Igor and Eduardo (who have been frequently rebasing onto each other, leading to some confusion on my part) with no final conclusion. For me it depends how different approaches work out patch-wise. On my x86 radar is this bulk: * finish CPU-as-a-device: the latest series does not realize/init CPUs unlike Anthony's earlier proposal, looks okay otherwise; will affect properties series and is affected by decisions about how to implement QOM realize * VMState: can we reuse DeviceClass::vmsd or do we need our own? open question from Juan's series: how to integrate machine.c VMState code? * subclasses: me having investigated fast-tracking host-x86-cpu; results negative, but starting to be untangled in new series. * sh4/alpha as small test runs for the proposed subclass type name scheme; issue: some targets like sh4 do case-insensitive name comparisons and (unposted) sh4 proposal of CPU name field search does not scale well; to-be-evaluated ideas beyond alpha v2: lower-casing in addition to appending -<arch>-cpu prefix; do we need a CPUClass callback for -cpu argument -> type name or is it a fully-custom per target decision? * avoid and fix the following bug: qemu-system-arm -cpu tmp105 * X86CPU subclasses: me investigating (with interruptions) a slim class_init-based conversion approach without waiting on all properties, to restructure the x86_def_t-centric helper functions * x86 CPU properties: there were still some naming issues in the last version I reviewed, ordering under discussion * HyperV properties: waiting on the previous properties series * QOM realize: if we do realize at device-level and the CPU becomes a device, it will benefit from the infrastructure but will need Object->DeviceState signature changes; realize at device-level cannot propagate recursively through non-device Container (e.g., "/machine", "/machine/unassigned") * lots of open issues: canonical paths for CPUs and their APIC etc. children; more CPU_COMMON->CPUState field moves needed for x86 socket-based hotplug; linux-user cpu_copy() / cpu_clone_regs(); icount field movements causing qtest failure; ... Plus obviously my attempts to bring the remaining non-x86 targets on par. Thanks again for your support in slowly crawling forward there. Andreas
On Sat, Dec 08, 2012 at 07:02:39PM +0100, Andreas Färber wrote: > Am 08.12.2012 18:54, schrieb Blue Swirl: > > Thanks, applied. > > As discussed this still leaves some cpudef cruft behind. > > Eduardo, can you please send a follow-up to move the versioning code and > kills all cpudef_*(), now that the patch got prematurely applied? Discussions about process aside, I don't see the relation between removing the entry for the "cpudef" config section from qemu-option.c (that's basically an unused variable, as no code used the config section since QEMU 1.2), and kiling the cpudef_*() functions (that aside from being named "cpudef_*", have nothing to do with the cpudef config section). Both cleanups are completely independent from each other.
On Mon, Dec 10, 2012 at 01:13:06AM +0100, Andreas Färber wrote: > Am 09.12.2012 21:46, schrieb Blue Swirl: > > On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <afaerber@suse.de> wrote: [...] > > What's for example the plan for Igor's series, should they be applied > > next or something else? > > I've been discussing our next steps with both Igor and Eduardo (who have > been frequently rebasing onto each other, leading to some confusion on > my part) with no final conclusion. For me it depends how different > approaches work out patch-wise. On my x86 radar is this bulk: > > * finish CPU-as-a-device: the latest series does not realize/init CPUs > unlike Anthony's earlier proposal, looks okay otherwise; will affect > properties series and is affected by decisions about how to implement > QOM realize This is holding the CPU properties work (that in turn is holding the CPU subclasses work, that will probably be much simpler to do using the CPU properties work as base). If there are no problems with the series, I would be very happy If we manage to get it in a pull request before new year. But I didn't get a single comment as reply to the v10 series, yet. :( > * VMState: can we reuse DeviceClass::vmsd or do we need our own? open > question from Juan's series: how to integrate machine.c VMState code? I haven't even considered how to address VMState. I hope other people are looking into that. :) > * subclasses: me having investigated fast-tracking host-x86-cpu; results > negative, but starting to be untangled in new series. I think I will probably be able to submit a RFC that converts "host" first (and in a very simple way), then convert the rest of CPU models. But I will send it as RFC because I think the results will look better after the CPU properties code is integrated. > * sh4/alpha as small test runs for the proposed subclass type name > scheme; issue: some targets like sh4 do case-insensitive name > comparisons and (unposted) sh4 proposal of CPU name field search does > not scale well; to-be-evaluated ideas beyond alpha v2: lower-casing in > addition to appending -<arch>-cpu prefix; do we need a CPUClass callback > for -cpu argument -> type name or is it a fully-custom per target decision? > * avoid and fix the following bug: qemu-system-arm -cpu tmp105 > * X86CPU subclasses: me investigating (with interruptions) a slim > class_init-based conversion approach without waiting on all properties, > to restructure the x86_def_t-centric helper functions I think we all converged to a class_init-based approach. We have your RFC, and I have a series to do that as well. Anyway I think we could at least convert the feature word fields into an array (series submitted by me this week), to simplify the -cpu check/enforce and -cpu host code. I plan to send a new x86-subclass RFC this week. > * x86 CPU properties: there were still some naming issues in the last > version I reviewed, ordering under discussion Right now I am waiting for a new version of the series from Igor, and I think it will be easier to implement X86CPU classes using it as base. (I don't know if he plans to submit a new version soon) > * HyperV properties: waiting on the previous properties series > * QOM realize: if we do realize at device-level and the CPU becomes a > device, it will benefit from the infrastructure but will need > Object->DeviceState signature changes; realize at device-level cannot > propagate recursively through non-device Container (e.g., "/machine", > "/machine/unassigned") I haven't looked at the QOM realize efforts, except by trying to make cpu_x86_realize() independent and separate from the rest of the X86CPU creation/initialization code. > * lots of open issues: canonical paths for CPUs and their APIC etc. > children; more CPU_COMMON->CPUState field moves needed for x86 > socket-based hotplug; linux-user cpu_copy() / cpu_clone_regs(); icount > field movements causing qtest failure; ... I consider the APIC-ID-related topology bug something we really need to fix in 1.4, and that probably can't wait until we remodel everything. Anyway, most of the work required in my experiments to fix the bug involved the PC initialization code (because we need to enable bug-compatible behavior on older machine-types), with small impact into the internal X86CPU code. I guess that's good news: some time ago the fix required lots of changes in the CPU initialization code, and now the CPU create()+realize() interface looks good enough to allow a simple fix to the problem without touching internal CPU code. > > Plus obviously my attempts to bring the remaining non-x86 targets on > par. Thanks again for your support in slowly crawling forward there. > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --git a/qemu-config.c b/qemu-config.c index 10d1ba4..aa78fb9 100644 --- a/qemu-config.c +++ b/qemu-config.c @@ -417,54 +417,6 @@ static QemuOptsList qemu_trace_opts = { }, }; -static QemuOptsList qemu_cpudef_opts = { - .name = "cpudef", - .head = QTAILQ_HEAD_INITIALIZER(qemu_cpudef_opts.head), - .desc = { - { - .name = "name", - .type = QEMU_OPT_STRING, - },{ - .name = "level", - .type = QEMU_OPT_NUMBER, - },{ - .name = "vendor", - .type = QEMU_OPT_STRING, - },{ - .name = "family", - .type = QEMU_OPT_NUMBER, - },{ - .name = "model", - .type = QEMU_OPT_NUMBER, - },{ - .name = "stepping", - .type = QEMU_OPT_NUMBER, - },{ - .name = "feature_edx", /* cpuid 0000_0001.edx */ - .type = QEMU_OPT_STRING, - },{ - .name = "feature_ecx", /* cpuid 0000_0001.ecx */ - .type = QEMU_OPT_STRING, - },{ - .name = "extfeature_edx", /* cpuid 8000_0001.edx */ - .type = QEMU_OPT_STRING, - },{ - .name = "extfeature_ecx", /* cpuid 8000_0001.ecx */ - .type = QEMU_OPT_STRING, - },{ - .name = "xlevel", - .type = QEMU_OPT_NUMBER, - },{ - .name = "model_id", - .type = QEMU_OPT_STRING, - },{ - .name = "vendor_override", - .type = QEMU_OPT_NUMBER, - }, - { /* end of list */ } - }, -}; - QemuOptsList qemu_spice_opts = { .name = "spice", .head = QTAILQ_HEAD_INITIALIZER(qemu_spice_opts.head), @@ -700,7 +652,6 @@ static QemuOptsList *vm_config_groups[32] = { &qemu_rtc_opts, &qemu_global_opts, &qemu_mon_opts, - &qemu_cpudef_opts, &qemu_trace_opts, &qemu_option_rom_opts, &qemu_machine_opts,
The external CPU models were removed on QEMU 1.2, and the support for the "cpudef" config sections was documented as deprecated, but the actual removal of the config section was pending. Now that QEMU 1.3 was released, we can finally kill the support for cpudef config sections, and support only the built-in CPU models from target-i386/cpu.c. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- qemu-config.c | 49 ------------------------------------------------- 1 file changed, 49 deletions(-)