linux-kernel - Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1471926684.5747.13.camel@intel.com>
Date:   Tue, 23 Aug 2016 04:31:26 +0000
From:   "Pandruvada, Srinivas" <srinivas.pandruvada@...el.com>
To:     "ahs3@...hat.com" <ahs3@...hat.com>,
        "ashwinch@...gle.com" <ashwinch@...gle.com>
CC:     "pprakash@...eaurora.org" <pprakash@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>
Subject: Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix
 user space reporting

On Mon, 2016-08-22 at 12:12 -0600, Al Stone wrote:
> On 08/22/2016 11:45 AM, Ashwin Chaugule wrote:
> > 
> > Hi Al,
> > 
> > On Mon, Aug 22, 2016 at 10:16 AM, Al Stone <ahs3@...hat.com> wrote:
> > > 
> > > Maybe a top-post will get attention....
> > > 
> > > Yet another ping; this was first submitted on 20 July, and has
> > > received
> > > no comments.  It has now been a month and other architectures are
> > > starting
> > > to use CPPC so they will run into the same errors that this
> > > fixes.  Can
> > > I get an ACK, NAK, or further instructions, please?
> > > 
> > 
> > Apologies for the delay. I thought this patch was merged already.
> 
> I've looked in linux-next and linux-pm; I could have missed it, but I
> didn't
> see it...my bad, if I did.
> 
> > 
> > > 
> > > Also adding Rafael on the ACPI side, just in case, since he's
> > > also reviewing
> > > the Intel patches on the linux-acpi mailing list that are adding
> > > CPPC usage.
> > > 
> > > On 08/11/2016 12:15 PM, Al Stone wrote:
> > > > 
> > > > On 08/01/2016 02:31 PM, Viresh Kumar wrote:
> > > > > 
> > > > > [+ Ashwin's new email id..]
> > > > > 
> > > > > On 20-07-16, 15:10, Al Stone wrote:
> > > > > > 
> > > > > > When CPPC is being used by ACPI on arm64, user space tools
> > > > > > such as
> > > > > > cpupower report CPU frequency values from sysfs that are
> > > > > > incorrect.
> > > > > > 
> > > > > > What the driver was doing was reporting the values given by
> > > > > > ACPI tables
> > > > > > in whatever scale was used to provide them.  However, the
> > > > > > ACPI spec
> > > > > > defines the CPPC values as unitless abstract
> > > > > > numbers.  Internal kernel
> > > > > > structures such as struct perf_cap, in contrast, expect
> > > > > > these values
> > > > > > to be in KHz.  When these struct values get reported via
> > > > > > sysfs, the
> > > > > > user space tools also assume they are in KHz, causing them
> > > > > > to report
> > > > > > incorrect values (for example, reporting a CPU frequency of
> > > > > > 1MHz when
> > > > > > it should be 1.8GHz).
> > > > > > 
> > > > > > The downside is that this approach has some assumptions:
> > > > > > 
> > > > > >    (1) It relies on SMBIOS3 being used, *and* that the Max
> > > > > > Frequency
> > > > > >    value for a processor is set to a non-zero value.
> > > > > > 
> > > > > >    (2) It assumes that all processors run at the same
> > > > > > speed, or that
> > > > > >    the CPPC values have all been scaled to reflect relative
> > > > > > speed.
> > > > > >    This patch retrieves the largest CPU Max Frequency from
> > > > > > a type 4 DMI
> > > > > >    record that it can find.  This may not be an issue,
> > > > > > however, as a
> > > > > >    sampling of DMI data on x86 and arm64 indicates there is
> > > > > > often only
> > > > > >    one such record regardless.  Since CPPC is relatively
> > > > > > new, it is
> > > > > >    unclear if the ACPI ASL will always be written to
> > > > > > reflect any sort
> > > > > >    of relative performance of processors of differing
> > > > > > speeds.
> > > > > > 
> > > > > >    (3) It assumes that performance and frequency both scale
> > > > > > linearly.
> > > > > > 
> > > > > > For arm64 servers, this may be sufficient, but it does rely
> > > > > > on
> > > > > > firmware values being set correctly.  Hence, other
> > > > > > approaches will
> > > > > > be considered in the future.
> > > > > > 
> > > > > > This has been tested on three arm64 servers, with and
> > > > > > without DMI, with
> > > > > > and without CPPC support.
> > > > > > 
> > > > > > Changes for v5:
> > > > > >     -- Move code to cpufreq/cppc_cpufreq.c from
> > > > > > acpi/cppc_acpi.c to keep
> > > > > >        frequency-related code together, and keep the CPPC
> > > > > > abstract scale
> > > > > >        in ACPI (Prashanth Prakash)
> > > > > >     -- Fix the scaling to remove the incorrect assumption
> > > > > > that frequency
> > > > > >        was always a range from zero to max; as a practical
> > > > > > matter, it is
> > > > > >        not (Prasanth Prakash); this also allowed us to
> > > > > > remove an over-
> > > > > >        engineered function to do this math.
> > > > > > 

In x86 when CPPC is used, the unit is really unit-less in CPPC tables.
This means that cpu->perf_caps.highest_perf can be just 0xff, instead
of some scaled cppc max performance corresponding to max MHZ the
processor can support. This allows the processor to cap at max which it
can deliver.
Is this case not possible for ARM SoCs?

Thanks,
Srinivas