linux-kernel - Re: [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services simultaneously

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]

Date:	Tue, 27 Jul 2010 19:56:28 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	linux-pci@...r.kernel.org, Len Brown <lenb@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native
	services simultaneously

On Tue, Jul 27, 2010 at 08:42:39PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 27, 2010, Matthew Garrett wrote:
> > I've done some more testing of this and found that my intial belief 
> > (supported by Microsoft's documentation...) that all PCIe support had to 
> > be handed over for any to be used is incorrect. It turns out that the 
> > firmware must support native hotplug, native power management and PCI 
> > express capability structure control - ie, SHPC and AER aren't required.
> 
> But the ACPI spec says quite explicitly that PCIe capability control is
> necessary for AER as well.

I may not have been clear. If the firmware doesn't report AER, Windows 
will use PME and hotplug. If the firmware doesn't support hotplug, 
Windows will *not* use PME or AER, and ditto if it doesn't support PME.

> > (2) If any of bits 0, 2 and 4 are unsupported, disable all PCIe support 
> > via _OSC
> 
> I guess you mean "don't request control of that services at all"?

I mean pass 0 as the third dword in our _OSC call.

> > (3) Ask for the set of supported bits & 0x1d
> 
> Really, if we try to treat native PME, native hot-plug and AER separately
> (which is our current approach), we fall into a Catch 22 situation where
> each of them needs PCIe capability control and once we've received the
> control of that, we have no choice but to use the other native sevices as well.

It seems that it's valid to have hotplug and PME without AER. The 
behaviour of Windows for each bit is:

0 Hotplug             Required
1 SHPHC               Will never request
2 PME                 Required
3 AER                 Optional
4 capability control  Required

So firmware can refuse to support SHPHC and AER and still get PCIe 
support, but if any of the required bits aren't available Windows won't 
use *any* of the _OSC-provided functions.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/