From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56165)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YpGHo-0007iM-U2
	for qemu-devel@nongnu.org; Mon, 04 May 2015 09:19:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YpGHl-0007gh-El
	for qemu-devel@nongnu.org; Mon, 04 May 2015 09:19:52 -0400
Received: from mx1.redhat.com ([209.132.183.28]:57083)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YpGHl-0007gZ-79
	for qemu-devel@nongnu.org; Mon, 04 May 2015 09:19:49 -0400
Message-ID: <554771E4.8070309@redhat.com>
Date: Mon, 04 May 2015 15:19:32 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1430421547-18278-1-git-send-email-ehabkost@redhat.com>	<20150504114728.0dd227dd@nial.brq.redhat.com>	<55474318.8090501@redhat.com>
	<20150504151616.1c93e84f@igors-macbook-pro.local>
In-Reply-To: <20150504151616.1c93e84f@igors-macbook-pro.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at
	/machine/cpus/<index>
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Igor Mammedov <imammedo@redhat.com>
Cc: peter.maydell@linaro.org, mimu@linux.vnet.ibm.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, bharata@linux.vnet.ibm.com, cornelia.huck@de.ibm.com, david@gibson.dropbear.id.au, =?windows-1252?Q?Andreas_F=E4rber?= <afaerber@suse.de>, Eduardo Habkost <ehabkost@redhat.com>



On 04/05/2015 15:16, Igor Mammedov wrote:
>> > 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.

CPUs would already be available at /machine/peripheral.  I think aliases
should provide alternative indexing whenever possible---not simply
filter by device type.

Paolo