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: <DM6PR19MB263622BBE4B699A0AA49977DFA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Mon, 5 Oct 2020 16:56:14 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Mark Pearson <markpearson@...ovo.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:11 p.m., Limonciello, Mario wrote:
> >>
> >> Excuse my ignorance, but I don't really see why this interface would be
> tied
> >> to
> >> ACPI devices? Why is it not possible to write a driver that implements this
> >> interface
> >> and directly modifies device registers? Am I missing something obvious
> here?
> >>
> >
> > 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.