Am 04.03.2014 15:00, schrieb Paolo Bonzini:
> This series includes all the pending work on QOMifying the memory
> backends.
[snip]
There's also a recent RFC from Chen Fan about how to model the
association between NUMA nodes and CPU socket/core/thread that
would/should influence this series if we're aiming for 2.1 now.
I didn't review it in-depth yet, but minor technical issues apart, I
think we need to keep NUMA and CPU separate, which then brings up the
question Chen Fan asked about whether we need to support splitting CPU
threads of one core or CPU cores of one socket onto different NUMA
nodes. If we can stop supporting this, 2.0 would be a good point in time
to catch this with an error message at least, even if the remodeling
depending on it happens post-2.0.
For example, assuming associativity at CPU socket level, I'd imagine:
/machine
/numa-node[0]
cpu[0] -> /machine/unassigned/device[0]
/unassigned
/device[0]
/core[0]
/thread[0]
I.e. the CPU socket is a self-contained object in /machine/unassigned
when machine-created or in /machine/peripheral when device_add'ed.
Hotplug will need a link<> property somewhere, and for a standard PC
this can be on /machine (Qseven modules, SoCs etc. would require it a
level down on their container but we don't support those yet). Having
the link<cpu>s on the NUMA nodes corresponds to having multiple buses in
the qdev world.
Compare that to:
/machine
/node[0] # This is not really telling!
/socket[0]
/core[0]
/thread[0] # So CPUState != thread?
cpu -> /machine/unassigned/device[0]
/unassigned
/device[0]
Note that according to my interpretation of QOM ABI stability rules we
can't just turn a link<cpu> into a child<cpu> without renaming, thus
trying to be forward-looking for where we want to go design-wise.
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
