Il 07/03/2014 13:56, Igor Mammedov ha scritto:
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).
Is there a point in having flat links to CPUState at /nodeX level,
Easily getting thread ids for the VCPU thread and pinning them to host
nodes? For this you need to match the CPU numbers passed to "-numa
node", not some socket topology that can be completely arbitrary.
Paolo
idea to create [*] /node[x]/socket[y]/core[z]/link<CPUstate>[j] tree, was
suggested as way:
1. to expose stable arch independent topology interface to user
2. use * as argument to -device / device_add/del cpu,path=foo to avoid
exposing arch dependent APIC ID to the user.
while keeping /machine/node/socket/core objects mostly as containers to express
above things.
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.
CPUState links are readonly only until no hotplug supported.
Paolo
