Il 07/03/2014 12:59, Andreas Färber ha scritto:
Am 05.03.2014 12:30, schrieb Paolo Bonzini:
Il 05/03/2014 12:05, Andreas Färber ha scritto:
I didn't review it in-depth yet, but minor technical issues apart, I
think we need to keep NUMA and CPU separate,
I agree.
Here you agreed ...
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]
I think this is better; in our world we can have multiple sockets in the
same NUMA node. But CPUState == thread, so you can have just /thread[0]
-> /machine/unassigned/device[0].
... but you seem to have missed my point about separation. Here the
socket object is a child<> of the NUMA node and would get realized
together with it but separate from the link<>ed CPUState.
Ah, I didn't think the socket object as anything but a container. For
me, "keep NUMA and CPU separate" meant "keep NUMA and CPUState separate".
Alternatively, and to keep CPU + NUMA even *more* separate:
/machine
/node[0]
/cpu[0] -> /machine/unassigned/device[0]
...
/socket[0]
/core[0]
/thread[0] -> /machine/unassigned/device[0]
/unassigned
/device[0]
Now this is pretty much my proposal ;) except that you retained the
criticized "node" as name and moved "socket[0]" out of
/machine/unassigned (I had /machine/peripheral in mind for -device) and
keep the CPUState out of the socket object.
Anthony had requested hot-add to happen via "device_add Xeon4242",
adding a full socket object with 6 cores at once. In that case CPUState
needs to be an integral part of that socket-derived device for recursive
realization. Objects that are just link<>ed to wouldn't get
automatically realized.
Yes, if you want to do this then you're right and /socket[n] needs to be
a device.
However, I'd still like it to be mostly a container, and that is why I
liked the idea of having /node[n] with "flat" links to the actual
CPUStates (and also memdevs).
I think we can. Children and links look exactly the same from the outside.
Well, we can't qom-get/qom-set a path string from/to a child<> property,
can we?
We can get it but not set it. But Stefan's series provides a way to
make links read-only too, and these links should be read-only I think.
Paolo
