linux-kernel - Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 18 Mar 2016 01:17:43 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Linda Knippers <linda.knippers@....com>
Cc:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	tony.luck@...el.com, bp@...en8.de, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, lenb@...nel.org,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

On Thursday, March 17, 2016 07:44:47 PM Linda Knippers wrote:
> 
> On 3/17/2016 5:12 PM, Srinivas Pandruvada wrote:
> <snip>
> >>>>> This needs to be done
> >>>>> before SMM code path looks for _OSC capabilities. The bit 12 of
> >>>>> _OSC in processor scope defines whether OS will handle thermal
> >>>>> interrupts.
> >>>>> When bit 12 is set to 1, OS will handle thermal interrupts.
> >>>>> Refer to this document for details on _OSC
> >>>>> http://www.intel.com/content/www/us/en/standards/processor-vend
> >>>>> or-
> >>>>> specific-acpi-specification.html
> >>>> Where is bit 12 documented?
> >>>>
> >>> In the above document.
> >> When I look at that document, I see bit 12 described as
> >> "If set, OSPM supports native interrupt handling for Collaborative
> >> Processor
> >> Performance Control notifications."  Is that the same thing or am
> >> I looking at the wrong table?
> > Yes. If you look at section 14.4 in Intel SDM, you will see that 
> > "HWP is an implementation of the ACPI-defined Collaborative Processor
> > Performance Control (CPPC)". Section 14.4.5 also specifies that HWP
> > uses IA32_THERM_STATUS to communicate if there are notifications, which
> > is notified via thermal interrupt.
> 
> Ok, thanks. That wasn't clear from the commit message.  It
> sounded like bit 12 directly indicated that the OS will handle
> thermal interrupts but it's a bit more indirect than that.
> 
> > You asked above if platform can handle these notification in SMM only.
> > If you do then the notification will arrive as ACPI notifications. We
> > don't have support for such notifications in Linux yet.
> 
> What I meant to ask was if the platform can disregard the _OSC information
> and handle thermal events on it's own, without OS involvement.
> For example, servers typically don't want to rely on the OS to manage
> thermal issues.
> 
> <snip>
> 
> >>>>> This change introduces a new function
> >>>>> acpi_early_processor_set_osc(),
> >>>>> which walks acpi name space and finds acpi processor object and
> >>>>> set capability via _OSC method to take over thermal LVT.
> >>>> Does this change just affect Skylake platforms or all platforms?
> >>> Any platform which has Intel ® Speed Shift Technology (aka HWP)
> >>> feature present and enabled.
> 
> Could this be an unexpected change in behavior for platforms
> with HWP that don't have this bug, assuming they would look at
> the _OSC CPPP bit?  That's actually my main concern here.

Do you have any specific platforms in mind or just in general?

Thanks,
Rafael