From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.25.208.137 with SMTP id h131csp1582367lfg; Mon, 9 May 2016 06:51:08 -0700 (PDT) X-Received: by 10.140.23.105 with SMTP id 96mr34395687qgo.7.1462801868101; Mon, 09 May 2016 06:51:08 -0700 (PDT) Return-Path: Received: from lists.gnu.org (lists.gnu.org. [2001:4830:134:3::11]) by mx.google.com with ESMTPS id v11si18703461qhv.31.2016.05.09.06.51.07 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 09 May 2016 06:51:08 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) client-ip=2001:4830:134:3::11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom=qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Received: from localhost ([::1]:41505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azlaV-0007o7-Nu for alex.bennee@linaro.org; Mon, 09 May 2016 09:51:07 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azla6-00074q-Ue for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azla5-0000a2-6g for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:42 -0400 Received: from foss.arm.com ([217.140.101.70]:36910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azlZz-0000ZQ-DR; Mon, 09 May 2016 09:50:35 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DE0F49; Mon, 9 May 2016 06:44:32 -0700 (PDT) Received: from localhost.localdomain (unknown [10.1.35.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EC9783F51B; Mon, 9 May 2016 06:44:18 -0700 (PDT) Date: Mon, 9 May 2016 13:44:11 +0000 From: Catalin Marinas To: Peter Maydell Message-ID: <20160509134410.GA2504@localhost.localdomain> References: <570B7048.5010501@arm.com> <570E1866.9010201@arm.com> <57306DA7.4010002@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 217.140.101.70 Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vijay Kilari , Suzuki K Poulose , Vijaya Kumar K , suresh knv , Vijaya Kumar K , Will Deacon , QEMU Developers , Prasun Kapoor , qemu-arm , Suresh , Paolo Bonzini Errors-To: qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-devel" X-TUID: T83FYjP0gFd/ On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote: > On 9 May 2016 at 11:59, Suzuki K Poulose wrote: > > Well, we have been waiting for a use case, like this, before we merge > > the series. > > This isn't a great strategy for moving people away from things > you'd like them to avoid like parsing /proc/cpuinfo, because typically > userspace app writers are not very interested in coding to facilities > which don't exist yet, and will prefer to make do with what's actually > present in the kernel today... You need to provide the improved API, > and then it needs to get out into kernel versions in distros and > otherwise, and only then are you likely to get app developers who > will start to say "this is useful". The problem is that the way kernel people think the API may be improved does not always match the use-cases required by app writers. One example here is exposing MIDR via MRS emulation, we know there are problems with big.LITTLE and the only clear answer I got so far is that we ignore such configurations. We don't even have a way to tell user space that this is a heterogeneous CPU configuration, unless we add another HWCAP bit specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS). That said, I'm perfectly fine with exposing: /sys/devices/system/cpu/cpu$ID/identification/ \- midr \- revidr I had the wrong impression that we already merged this part but Suzuki just pointed out to me that it's not. I think our 4.7-rc1 tree is pretty much frozen to new features now, though the sysfs patch is relatively small (I'll let Will comment): https://patches.linaro.org/patch/54502/ The MRS emulation, we should restart the discussion around big.LITTLE implications and make a decision one way or another by the 4.8 merging window. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azla6-00074q-Ue for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azla5-0000a2-6g for qemu-devel@nongnu.org; Mon, 09 May 2016 09:50:42 -0400 Date: Mon, 9 May 2016 13:44:11 +0000 From: Catalin Marinas Message-ID: <20160509134410.GA2504@localhost.localdomain> References: <570B7048.5010501@arm.com> <570E1866.9010201@arm.com> <57306DA7.4010002@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Suzuki K Poulose , Vijay Kilari , Will Deacon , Vijaya Kumar K , qemu-arm , Paolo Bonzini , QEMU Developers , Prasun Kapoor , suresh knv , Vijaya Kumar K , Suresh On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote: > On 9 May 2016 at 11:59, Suzuki K Poulose wrote: > > Well, we have been waiting for a use case, like this, before we merge > > the series. > > This isn't a great strategy for moving people away from things > you'd like them to avoid like parsing /proc/cpuinfo, because typically > userspace app writers are not very interested in coding to facilities > which don't exist yet, and will prefer to make do with what's actually > present in the kernel today... You need to provide the improved API, > and then it needs to get out into kernel versions in distros and > otherwise, and only then are you likely to get app developers who > will start to say "this is useful". The problem is that the way kernel people think the API may be improved does not always match the use-cases required by app writers. One example here is exposing MIDR via MRS emulation, we know there are problems with big.LITTLE and the only clear answer I got so far is that we ignore such configurations. We don't even have a way to tell user space that this is a heterogeneous CPU configuration, unless we add another HWCAP bit specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS). That said, I'm perfectly fine with exposing: /sys/devices/system/cpu/cpu$ID/identification/ \- midr \- revidr I had the wrong impression that we already merged this part but Suzuki just pointed out to me that it's not. I think our 4.7-rc1 tree is pretty much frozen to new features now, though the sysfs patch is relatively small (I'll let Will comment): https://patches.linaro.org/patch/54502/ The MRS emulation, we should restart the discussion around big.LITTLE implications and make a decision one way or another by the 4.8 merging window. -- Catalin