Re: [Qemu-devel] [PATCH] finally kill cpudef config section support

[Eduardo Habkost]

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 <address@hidden> 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

-- 
Eduardo