On Tue, Apr 24, 2012 at 11:00:49AM +0200, Andreas Färber wrote:
> Am 19.04.2012 20:27, schrieb Eduardo Habkost:
> > By the way, do you still plan to make cpudefs register new
> > classes/types? I remember that you did that on a previous series.
>
> Generally I do, yes. However the CPU QOM'ification is not making as much
> progress as I would've liked, specifically there's still five targets
> left in my queue for base QOM'ification for 1.1.
>
> This series, x86 part 2, goes further and prepares properties a) for
> general inspection and modification (but without having the CPU exposed
> as a child yet), b) for use in instantiating subclasses in part 3. It
> was intended for 1.1.
>
> Question is, do we want CPU subclasses for 1.1? ARM has them now but we
> won't manage to unify this across targets in time for the Hard Freeze.
>
> For ARM there was a dislike of the ARMCPUClass-based approach and a
> preference towards hardcoding things imperatively in initfns. I don't
> see how that would work for cpudef, so I would stick with extending
> X86CPUClass.
>
> There was a dislike of duplicating fields between X86CPUInfo and
> X86CPUClass. However to avoid incurring a sub-struct access the only way
> would be to move the field definitions to a macro and use it in both
> locations. Further opinions or suggestions welcome.
I don't see anything wrong with having a sub-struct (and I don't like
using macros to define struct fields).
We could also make the CPU objects/structs simply hold a pointer to a
CPUClass struct, and store the common CPU definitions/features on a
single place, in case they are really not mutable per-CPU data.
>
> I've also not yet seen a discussion whether we need to allow modifying
> built-in classes via cpudef or whether adding new classes is sufficient.
> I had implemented both in my RFC but would prefer the latter if there is
> agreement.
I would like to move the built-in CPU models to configuration-file
cpudefs, at least on i386, so there wouldn't be any "built-in" CPU model
anymore.
>
> > Is it possible to have property get/setters for ObjectClass QOM objects,
> > too? It would be interesting to use QOM properties for the cpudef fields
> > as well (it would make the work of defining boolean feature fields much
> > simpler).
>
> No. Classes do not have property infrastructure and I personally see
> them as immutable. cpudef is independent of classes though, so you could
> invent a new mechanism to set/unset features, whatever the backend
> they'll be written to.
I am still confused by the terminology, here. Let me try to enumerate
the kind of entities involved:
- There is one <CPU object> for each vCPU
- This is what you have just converted to QOM on this series
(correct?).
- <CPUClass> is the class for QOM CPU objects
- <CPUX86Class> is a x86-specific class for CPU objects
- <cpudef> is a x86-specific mechanism to define new CPU models
to be used as template for CPUs
- It's not clear how cpudefs are going to be represented: as a
separate kind of object? As CPUX86Class subclasses?
- This is the area I have been looking at, and I would like to make it
use the QOM infra-structure, and map configuration file fields to
object properties, but I don't know what's the best way to do that.
- <-cpu command-line options> are defined on the command-line, and
currently it's not as powerful and use a completely different
mechanism from cpudef
- I would like to eliminated this asymmetry and make cpudef and -cpu
use exactly the same mechanism to define CPU properties
Is anything missing in the list above?
I don't know what's the model used on other architectures. I guess most
architectures just have a single CPU class, have no concept of
"cpudefs", but support the -cpu command-line option (do they?).
It's not clear to me what's the data model we are aiming to. Some of the
entities above may be merged with others, some may become QOM objects,
some may be kept as plain C structs like we do today, some may become
QOM classes. Is there a clear plan already, or are we still defining
what to do?
--
Eduardo
