From patchwork Fri Jul 18 13:57:38 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 33854 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pa0-f70.google.com (mail-pa0-f70.google.com [209.85.220.70]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 12FA220CA0 for ; Fri, 18 Jul 2014 13:59:29 +0000 (UTC) Received: by mail-pa0-f70.google.com with SMTP id lf10sf27970268pab.5 for ; Fri, 18 Jul 2014 06:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:subject:message-id :references:mime-version:in-reply-to:user-agent:cc:precedence :list-id:list-unsubscribe:list-archive:list-post:list-help :list-subscribe:sender:errors-to:x-original-sender :x-original-authentication-results:mailing-list:content-disposition :content-type:content-transfer-encoding; bh=gdAhzHM/SxfvzlActBtztTJHPP7Nq2FOScmHAUwKJsM=; b=K2w4gIodq6ekwEriEvbK0ol8RDlyuX+a3wTyXrYy8sr3bGc5iw4FBG+La+S37GF0Z3 GZ2RN5rkXlD/gcqR3ttZocC0SajkERMJV80iydbRve7VSfxhR6iNE09O/Oa1cixDEmdZ Nt44SoHFWmywh0VfssbO+fyq5idv2H8wwbT2gzf5vTAcePfZkD2DRdupelWyjLCwR52E d6KCXEUBjzNk+9gyQT/vmJaMGRLF1ZzNoiIP9AFrgxvP7bbWk5TgyI422fOltNKwXLRW V2wVhAlggnLd4Fm5d+GT4flvE9kQnqCdgNdaWKGu3W0uIy4NP3BisUT3nfO154YnnGLm lO0Q== X-Gm-Message-State: ALoCoQkCs4KZGq5GNPHkOzjPaXN2TsrKv1SxL6I14WQGzFSq0cuNQq5msrMxAh20/zEAFQBPCTxK X-Received: by 10.66.121.163 with SMTP id ll3mr2536930pab.26.1405691969296; Fri, 18 Jul 2014 06:59:29 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.95.193 with SMTP id i59ls988680qge.20.gmail; Fri, 18 Jul 2014 06:59:29 -0700 (PDT) X-Received: by 10.220.80.142 with SMTP id t14mr5931096vck.55.1405691969183; Fri, 18 Jul 2014 06:59:29 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPS id fw5si5766529vcb.46.2014.07.18.06.59.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 06:59:29 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; Received: by mail-vc0-f174.google.com with SMTP id la4so7396109vcb.33 for ; Fri, 18 Jul 2014 06:59:29 -0700 (PDT) X-Received: by 10.52.120.38 with SMTP id kz6mr5062838vdb.86.1405691968909; Fri, 18 Jul 2014 06:59:28 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.37.5 with SMTP id tc5csp13469vcb; Fri, 18 Jul 2014 06:59:28 -0700 (PDT) X-Received: by 10.70.87.229 with SMTP id bb5mr5231081pdb.125.1405691963762; Fri, 18 Jul 2014 06:59:23 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id og1si2689059pdb.295.2014.07.18.06.59.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jul 2014 06:59:23 -0700 (PDT) Received-SPF: none (google.com: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org does not designate permitted sender hosts) client-ip=2001:1868:205::9; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1X88fx-0001SC-P7; Fri, 18 Jul 2014 13:58:17 +0000 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1X88ft-00011a-Id for linux-arm-kernel@lists.infradead.org; Fri, 18 Jul 2014 13:58:14 +0000 Received: from leverpostej (leverpostej.cambridge.arm.com [10.1.205.151]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id s6IDvjwo021618; Fri, 18 Jul 2014 14:57:45 +0100 (BST) Date: Fri, 18 Jul 2014 14:57:38 +0100 From: Mark Rutland To: Will Deacon Subject: Re: [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs Message-ID: <20140718135738.GA17328@leverpostej> References: <53C7A980.8050601@arm.com> <20140717105415.GI21153@arm.com> <20140717123533.GJ21153@arm.com> <20140717171058.GM18203@arm.com> <20140717172858.GD4844@arm.com> <20140718092744.GA19850@arm.com> <20140718095311.GA1818@arm.com> MIME-Version: 1.0 In-Reply-To: <20140718095311.GA1818@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140718_065813_960903_4BE2CB37 X-CRM114-Status: GOOD ( 31.32 ) X-Spam-Score: -5.0 (-----) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-5.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.96.50 listed in list.dnswl.org] -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record Cc: Catalin Marinas , "ard.biesheuvel@linaro.org" , Marcus Shawcroft , "linux-arm-kernel@lists.infradead.org" , Peter Maydell X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: mark.rutland@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 Content-Disposition: inline On Fri, Jul 18, 2014 at 10:53:12AM +0100, Will Deacon wrote: > On Fri, Jul 18, 2014 at 10:27:44AM +0100, Catalin Marinas wrote: > > On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote: > > > On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote: > > > > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > > > > > On 17 July 2014 13:35, Will Deacon wrote: > > > > > > We're not denying the possibility of heterogeneity, we're trying to expose a > > > > > > consistent view of the system to userspace. Differences between cores should > > > > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > > > > > passed off to userspace. > > > > > > > > > > On that basis, why report anything at all about invididual cores? > > > > > Just have /proc/cpuinfo report "number of processors: 4" and > > > > > no per-CPU information at all... > > > > > > > > We lost a lot of time on this already (given the internal threads). So > > > > my proposal is to go ahead with Mark's patch with per-CPU features. They > > > > currently just include the same elf_hwcap multiple times. If we ever > > > > need to present different features, the conditions would be: > > > > > > > > 1. Never report more than elf_hwcap > > > > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a > > > > way to transparently handle migration or emulation > > > > > > ... making the point of a per-cpu field entirely pointless ;) > > > > Well, if we can support such features in a transparent way, > > /proc/cpuinfo becomes more informative (e.g. user wondering why a > > process runs only on certain CPUs). > > > > But to be clear (and I think we are aligned), I don't trust user space > > to parse all processors in /proc/cpuinfo and make an informed selection > > of CPU affinity to avoid SIGILL. > > > > Yet another option would be to have a single features/hwcap line and > > present the extra features in a human (and only human) readable form > > (e.g. some haiku that changes with every kernel release ;)). > > Or just have the single features line, then the per-cpu line can be called > `flags' or something, like Ard suggested. If userspace decides to parse > flags, it deserves all the pain that it gets. Ok. I think retaining the current (common) features line makes sense if it's clearly separated from any particular CPU. If we need per-cpu information later, this can be in addition to the common line. That should enable software which only does mildy crazy things with values from /proc/cpuinfo to work even if we print per-cpu information. Anything trying to handle per-cpu differences will need rework regardless, and that discussion can be had when we actually have crazily heterogeneous systems. Therefore, how about the below? Thanks, Mark. ---->8---- >From 7dc7b5e5c4a54f56a5a7e59d2dd0de009dc9b9d0 Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Thu, 26 Jun 2014 16:18:44 +0100 Subject: [PATCH] arm64: cpuinfo: print info for all CPUs Currently reading /proc/cpuinfo will result in information being read out of the MIDR_EL1 of the current CPU, and the information is not associated with any particular logical CPU number. This is problematic for systems with heterogeneous CPUs (i.e. big.LITTLE) where MIDR fields will vary across CPUs, and the output will differ depending on the executing CPU. This patch reorganises the code responsible for /proc/cpuinfo to print information per-cpu. In the process, we perform several cleanups: * Property names are coerced to lower-case (to match "processor" as per glibc's expectations). * Property names are simplified and made to match the MIDR field names. * Revision is changed to hex as with every other field. * The meaningless Architecture property is removed. * The ripe-for-abuse Machine field is removed. The features field (a human-readable representation of the hwcaps) remains printed once, as this is expected to remain in use as the globally support CPU features. To enable the possibility of the addition of per-cpu HW feature information later, this is printed before any CPU-specific information. Comments are added to guide userspace developers in the right direction (using the hwcaps provided in auxval). Hopefully where userspace applications parse /proc/cpuinfo rather than using the readily available hwcaps, they limit themselves to reading said first line. If CPU features differ from each other, the previously installed sanity checks will give us some advance notice with warnings and TAINT_CPU_OUT_OF_SPEC. If we are lucky, we will never see such systems. Rework will be required in many places to support such systems anyway. Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Marcus Shawcroft Cc: Peter Maydell Cc: Will Deacon --- arch/arm64/kernel/setup.c | 37 ++++++++++++++++++------------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index edb146d..aaf1ddb 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -450,10 +450,21 @@ static int c_show(struct seq_file *m, void *v) { int i; - seq_printf(m, "Processor\t: %s rev %d (%s)\n", - cpu_name, read_cpuid_id() & 15, ELF_PLATFORM); + /* + * Dump out the common processor features in a single line. Userspace + * should read the hwcaps with getauxval(AT_HWCAP) rather than + * attempting to parse this. + */ + seq_puts(m, "features\t:"); + for (i = 0; hwcap_str[i]; i++) + if (elf_hwcap & (1 << i)) + seq_printf(m, " %s", hwcap_str[i]); + seq_puts(m, "\n\n"); for_each_online_cpu(i) { + struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i); + u32 midr = cpuinfo->reg_midr; + /* * glibc reads /proc/cpuinfo to determine the number of * online processors, looking for lines beginning with @@ -462,25 +473,13 @@ static int c_show(struct seq_file *m, void *v) #ifdef CONFIG_SMP seq_printf(m, "processor\t: %d\n", i); #endif + seq_printf(m, "implementer\t: 0x%02x\n", + MIDR_IMPLEMENTOR(midr)); + seq_printf(m, "variant\t\t: 0x%x\n", MIDR_VARIANT(midr)); + seq_printf(m, "partnum\t\t: 0x%03x\n", MIDR_PARTNUM(midr)); + seq_printf(m, "revision\t: 0x%x\n\n", MIDR_REVISION(midr)); } - /* dump out the processor features */ - seq_puts(m, "Features\t: "); - - for (i = 0; hwcap_str[i]; i++) - if (elf_hwcap & (1 << i)) - seq_printf(m, "%s ", hwcap_str[i]); - - seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24); - seq_printf(m, "CPU architecture: AArch64\n"); - seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); - seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff); - seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15); - - seq_puts(m, "\n"); - - seq_printf(m, "Hardware\t: %s\n", machine_name); - return 0; }