linux-kernel - Re: [External] RE: [RFC] Documentation: Add documentation for new performance

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: <26662fd8-1bd8-94b9-2fa6-6b1c1c96481d@lenovo.com>
Date:   Mon, 5 Oct 2020 13:46:47 -0400
From:   Mark Pearson <markpearson@...ovo.com>
To:     "Limonciello, Mario" <Mario.Limonciello@...l.com>,
        Barnabás Pőcze <pobrn@...tonmail.com>
CC:     Hans de Goede <hdegoede@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Mark Gross <mgross@...ux.intel.com>,
        Mark Pearson <mpearson@...ovo.com>,
        Elia Devito <eliadevito@...il.com>,
        Bastien Nocera <hadess@...ess.net>,
        Benjamin Berg <bberg@...hat.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [External] RE: [RFC] Documentation: Add documentation for new
 performance_profile sysfs class



On 2020-10-05 12:56 p.m., Limonciello, Mario wrote:
>>>
>>> When implemented for the two vendors mentioned here, it would be using a
>>> proprietary "firmware API" implemented by those two vendors.  For example
>> write
>>> arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to
>> coordinate
>>> using undisclosed protocol to affect the platform changes desirable.
>>>
>>> This is different in my mind from "kernel writes to a specific register" to
>> set
>>> power properties of a specific device.
>>>
>>
>> Just curious on this point - isn't that (mostly) what all hardware does?
>> You write to it and the device does "stuff" to achieve the required
>> effect. Yes this is in proprietary firmware, but from my experience with
>> hardware devices that's not uncommon these days anyway.
>>
> 
> Yes I agree.  Even "register" writes to a device are actually an API and
> something in the hardware monitors those registers and does something as a
> result.
> 
>> Let me know if I'm misunderstanding something here. I couldn't see the
>> difference between a register written to via ACPI and one written to via
>> some other protocol (SMBUS? or whatever)
>>
>> Mark
>>
> 
> The reason I'm calling out a distinction here is that "platform" and "device"
> can cover a lot more things.  In this case it's an API provided by the platform's
> firmware, not an individual device's firmware.  So you can't actually guarantee
> what the platform's firmware did.  It could have sent any number of sideband
> commands to devices that it controls.  The "platform" could have potentially
> told the GPU to turn up its fans, or lower it's clock as a result of this, but you
> can't possibly know.
> 
> However if we go the GPU example alone, it's a specific single device you're
> controlling.  You put the GPU into the characterization that you expected and it
> operates that way.
> 
Got it - fair enough :) Thanks for the explain.
Thanks
Mark