On Fri, 07 Mar 2014 14:35:09 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote:
> 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. CPU numbers, on -numa node, are coming from cpu_index legacy, and shouldn't we try to get rid of it in favor of something manageable? Since CPUs are now devices we could use "id" to specify CPUs on -numa node as one solution or use path names as with memdev. > > 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 > > > > > -- Regards, Igor
