From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4IvG-0007xR-HV for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:43:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4IvD-0000oy-BU for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:43:02 -0500 Received: from e19.ny.us.ibm.com ([129.33.205.209]:42099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4IvD-0000oe-8S for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:42:59 -0500 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 Dec 2015 20:42:57 -0500 Date: Wed, 2 Dec 2015 17:42:44 -0800 From: Sukadev Bhattiprolu Message-ID: <20151203014244.GA16046@us.ibm.com> References: <1447467188-4458-1-git-send-email-sukadev@linux.vnet.ibm.com> <1447467188-4458-2-git-send-email-sukadev@linux.vnet.ibm.com> <20151127064738.GD25500@voom.redhat.com> <20151201194931.GA22634@us.ibm.com> <20151202023257.GB3107@voom.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151202023257.GB3107@voom.redhat.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 2/2] target-ppc: Implement rtas_get_sysparm(PROCESSOR_MODULE_INFO) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: stewart@linux.vnet.ibm.com, thuth@redhat.com, benh@au1.ibm.com, nacc@linux.vnet.ibm.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, paulus@au1.ibm.com David Gibson [david@gibson.dropbear.id.au] wrote: | > Should we walk the /proc/device-tree/cpus/ tree and count only dirs with | > device-type "cpu" (rather than relying on the pattern PowerPC,POWER*)? | | Yes, I think you'll have to. | Ok. Are we ok with the xscom check I have (copied below): +static int kvmppc_count_sockets_chips_dt(int *num_sockets, int *num_chips) +{ + const char *chip_pattern = "/proc/device-tree/xscom@*/ibm,chip-id"; + const char *module_pattern = "/proc/device-tree/xscom@*/ibm,hw-module-id"; --- I am not sure of a reliable way to detect number of chips besides the xscom. I do see that sysfs has node entries: for i in `ls -d /sys/bus/cpu/devices/cpu*`; > do > basename $i/node* > done | sort | uniq node0 node1 node16 node17 which seems to correspond to $ lsprop /proc/device-tree/xscom@*/ibm,chip-id /proc/device-tree/xscom@3fc0000000000/ibm,chip-id 00000000 /proc/device-tree/xscom@3fc0800000000/ibm,chip-id 00000001 /proc/device-tree/xscom@3fc8000000000/ibm,chip-id 00000010 (16) /proc/device-tree/xscom@3fc8800000000/ibm,chip-id 00000011 (17) but is that reliable? > + | > | | > | In a number of ways I'd actually prefer to move to /cpus/cpu@NNN in | > | general, since that follows the OF generic names recommendation we | > | follow for most other nodes. | > | > Do you mean rename '/proc/device-tree/cpus/PowerPC,POWER8@NNN' to | > /proc/device-tree/cpus/cpu@NNN? | | Yes. This is a firmware matter, so it's not something that can simply | be changed everywhere, but it's the approach that I'd prefer to | encourage for people making future machines and firmwares. Sure. ppc64_cpu also seems to rely on '/proc/device-tree/cpus/PowerPC' to count cores present and maybe there are other utilities that would need to be updated. Sukadev