From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suzuki.Poulose@arm.com (Suzuki K. Poulose) Date: Fri, 25 Sep 2015 14:05:52 +0100 Subject: [PATCH 07/22] arm64: Keep track of CPU feature registers In-Reply-To: <20150925113808.GL6281@e103592.cambridge.arm.com> References: <1442413280-31885-1-git-send-email-suzuki.poulose@arm.com> <1442413280-31885-8-git-send-email-suzuki.poulose@arm.com> <20150925113808.GL6281@e103592.cambridge.arm.com> Message-ID: <560546B0.7070909@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 25/09/15 12:38, Dave P Martin wrote: > On Wed, Sep 16, 2015 at 03:21:05PM +0100, Suzuki K. Poulose wrote: >> From: "Suzuki K. Poulose" >> >> This patch adds an infrastructure to keep track of the CPU feature >> registers on the system. For each register, the infrastructure keeps >> track of the system wide safe value of the feature bits. Also, tracks >> the which fields of a register should be matched strictly across all >> the CPUs on the system for the SANITY check infrastructure. >> >> The feature bits are classified as one of SCALAR_MIN, SCALAR_MAX and DISCRETE >> depending on the implication of the possible values. This information >> is used to decide the safe value for a feature. >> >> SCALAR_MIN - The smaller value is safer >> SCALAR_MAX - The bigger value is safer >> DISCRETE - We can't decide between the two, so a predefined safe_value is used. > > Can documentation of the meanings of these be added somewhere in the > relevant header or in Documentation? Sure. They were part of the initial draft and eventually lost them over the reworks. I will add them back, since there is wider use of the information across the system, from what I started with(i.e, Userspace visibility). Cheers Suzuki From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756487AbbIYNF5 (ORCPT ); Fri, 25 Sep 2015 09:05:57 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:56149 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756440AbbIYNFz convert rfc822-to-8bit (ORCPT ); Fri, 25 Sep 2015 09:05:55 -0400 Message-ID: <560546B0.7070909@arm.com> Date: Fri, 25 Sep 2015 14:05:52 +0100 From: "Suzuki K. Poulose" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave P Martin CC: "linux-arm-kernel@lists.infradead.org" , Mark Rutland , "ard.biesheuvel@linaro.org" , "aph@redhat.com" , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , "edward.nevill@linaro.org" , Andre Przywara , Marc Zyngier Subject: Re: [PATCH 07/22] arm64: Keep track of CPU feature registers References: <1442413280-31885-1-git-send-email-suzuki.poulose@arm.com> <1442413280-31885-8-git-send-email-suzuki.poulose@arm.com> <20150925113808.GL6281@e103592.cambridge.arm.com> In-Reply-To: <20150925113808.GL6281@e103592.cambridge.arm.com> X-OriginalArrivalTime: 25 Sep 2015 13:05:52.0616 (UTC) FILETIME=[E82AF680:01D0F792] X-MC-Unique: 4sXdFze6QjmZBFYwr67uPw-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/09/15 12:38, Dave P Martin wrote: > On Wed, Sep 16, 2015 at 03:21:05PM +0100, Suzuki K. Poulose wrote: >> From: "Suzuki K. Poulose" >> >> This patch adds an infrastructure to keep track of the CPU feature >> registers on the system. For each register, the infrastructure keeps >> track of the system wide safe value of the feature bits. Also, tracks >> the which fields of a register should be matched strictly across all >> the CPUs on the system for the SANITY check infrastructure. >> >> The feature bits are classified as one of SCALAR_MIN, SCALAR_MAX and DISCRETE >> depending on the implication of the possible values. This information >> is used to decide the safe value for a feature. >> >> SCALAR_MIN - The smaller value is safer >> SCALAR_MAX - The bigger value is safer >> DISCRETE - We can't decide between the two, so a predefined safe_value is used. > > Can documentation of the meanings of these be added somewhere in the > relevant header or in Documentation? Sure. They were part of the initial draft and eventually lost them over the reworks. I will add them back, since there is wider use of the information across the system, from what I started with(i.e, Userspace visibility). Cheers Suzuki