Patchwork finally kill cpudef config section support

login
register
mail settings
Submitter Eduardo Habkost
Date Dec. 4, 2012, 6:32 p.m.
Message ID <1354645978-17362-1-git-send-email-ehabkost@redhat.com>
Download mbox | patch
Permalink /patch/203716/
State New
Headers show

Comments

Eduardo Habkost - Dec. 4, 2012, 6:32 p.m.
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(-)
Andreas Färber - Dec. 4, 2012, 6:41 p.m.
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,
>
Eduardo Habkost - Dec. 4, 2012, 6:53 p.m.
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
>
Blue Swirl - Dec. 8, 2012, 5:54 p.m.
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
>
>
Andreas Färber - Dec. 8, 2012, 6:02 p.m.
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
Blue Swirl - Dec. 8, 2012, 8 p.m.
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
Andreas Färber - Dec. 9, 2012, 7:13 p.m.
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
Andreas Färber - Dec. 9, 2012, 7:45 p.m.
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(-)
Blue Swirl - Dec. 9, 2012, 8:46 p.m.
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
Andreas Färber - Dec. 10, 2012, 12:13 a.m.
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
Eduardo Habkost - Dec. 10, 2012, 6:03 p.m.
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.
Eduardo Habkost - Dec. 12, 2012, 1:03 p.m.
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

Patch

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,