On Mon, May 04, 2015 at 03:16:16PM +0200, Igor Mammedov wrote: > On Mon, 04 May 2015 11:59:52 +0200 > Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > > > > On 04/05/2015 11:47, Igor Mammedov wrote: > > > On Thu, 30 Apr 2015 16:19:07 -0300 > > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > > > This will provide a predictable path for the CPU objects, and a > > > > more powerful alternative for the query-cpus QMP command, as now > > > > every QOM property on CPU objects can be easily queried. > > > > > > provided the way cpu_index is generated, path won't be > > > predictable/stable with CPU unplug. I'd rather use DEVICE->id > > > instead of cpu_index. > > > > Can we use the APIC id then? Perhaps wrapped with a CPUState-level > > method get_stable_processor_id()? > We have CPUClass->get_arch_id() which results in APIC id for > target-i386. > But I'd rather see an arbitrary DEVICE->id as index/name, that way > when -device cpu-foo,id=cpuXXX becomes functional we would have > 1:1 mapping between CLI and /machine/cpus/ view.
An arbitrary device ID sounds better to me, because it allows us to change guest-visible behavior without breaking QMP client expectations. The only question is what should be the default device ID for the CPUs created by -smp and cpu-add. I was going to suggest get_arch_id(), but cpu_index may be a better candidate for the same reason above: it is truly an arbitrary ID that doesn't depend on guest-visible bits. -- Eduardo
