From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpIhE-0003SI-NA for qemu-devel@nongnu.org; Mon, 04 May 2015 11:54:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpIhD-0002sm-3G for qemu-devel@nongnu.org; Mon, 04 May 2015 11:54:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpIhC-0002sg-Rt for qemu-devel@nongnu.org; Mon, 04 May 2015 11:54:15 -0400 Message-ID: <55479617.9070903@redhat.com> Date: Mon, 04 May 2015 17:53:59 +0200 From: Paolo Bonzini 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> <554771E4.8070309@redhat.com> <20150504140558.GL17796@thinpad.lan.raisama.net> In-Reply-To: <20150504140558.GL17796@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost 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, Igor Mammedov , =?windows-1252?Q?Andreas_F=E4rber?= , david@gibson.dropbear.id.au On 04/05/2015 16:05, Eduardo Habkost wrote: > On Mon, May 04, 2015 at 03:19:32PM +0200, Paolo Bonzini wrote: >> >> >> 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. > > [1] Is there anybody or any document that can explain to me what all the > containers inside /machine mean? I see /machine/peripheral, > /machine/peripheral-anon, /machine/unattached, here, and I don't > know what they mean. /machine/peripheral/XYZ holds devices created with -device id=XYZ /machine/peripheral-anon/device[NN] holds devices created without an id /machine/unattached holds devices created by the board and not added elsewhere through object_property_add_child. > Could you clarify what you mean by "alternative indexing"? A way to lookup devices of a particular kind. An example of "alternative indexing" is using pci.0/child[NN] to look up children of the first PCI bus. > All I am trying to provide right now is having a predictable path for > CPUs, it doesn't matter if using -device, device_add, -smp, or cpu-add. > Filtering by device type is not what I need, here. Ok, so we're on the same page. I would use any of: - /machine/cpus/NN (your choice) - /machine/cpu[NN] (Peter's choice) - /machine/cpus/cpu[NN] (hybrid, resembles /machine/peripheral-anon or /machine/unattached more) I'm not sure if "NN" should be a random progressive number (in that case you can use cpu[*] to let the QOM core pick the number) or the APIC ID. You know the domain better than I do. > Making the path depend on guest-visible bits that can change depending > on the architeture or machine would make the path less predictable. You can still list all children of /machine/cpus. The disadvantage of the APIC ID is that IDs may have holes even without doing any hot-unplug; the advantage is that, from a set of online CPUs in the guest, you can predict the paths in /machine/cpus. With cpu[*] instead you can have different contents of /machine/cpus after for example cpu_add 3 # adds /machine/cpus/cpu[2] pointing to CPU 3 cpu_add 2 # adds /machine/cpus/cpu[3] pointing to CPU 2 vs. cpu_add 2 # adds /machine/cpus/cpu[2] pointing to CPU 2 cpu_add 3 # adds /machine/cpus/cpu[3] pointing to CPU 3 > I have an alternative patch that simply adds a "qom-path" field to > query-cpus. If we find out that making commitments about QOM paths is > too hard, I can submit it instead. I don't think it's too hard, but this alternative patch may also make sense. Paolo