linux-kernel - Re: [RFC][PATCH v2]: PCI: PCIe links may not get configured for ASPM under POWERSAVE mode

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] [day] [month] [year] [list]

Message-ID: <4D880665.5010006@jp.fujitsu.com>
Date:	Tue, 22 Mar 2011 11:16:05 +0900
From:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To:	"Chumbalkar, Nagananda" <Nagananda.Chumbalkar@...com>
CC:	"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
	"rjw@...k.pl" <rjw@...k.pl>,
	"mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [RFC][PATCH v2]: PCI: PCIe links may not get configured for ASPM
 under POWERSAVE mode

(2011/03/18 23:52), Chumbalkar, Nagananda wrote:
>
>> -----Original Message-----
>> From: Kenji Kaneshige [mailto:kaneshige.kenji@...fujitsu.com]
>> Sent: Friday, March 18, 2011 12:29 AM
>> To: Chumbalkar, Nagananda
>> Cc: jbarnes@...tuousgeek.org; rjw@...k.pl; mjg59@...f.ucam.org; linux-
>> kernel@...r.kernel.org; linux-pci@...r.kernel.org
>> Subject: Re: [RFC][PATCH v2]: PCI: PCIe links may not get configured for
>> ASPM under POWERSAVE mode
>>
>> (2011/03/18 13:21), Naga Chumbalkar wrote:
>>> v2 ->   v1:
>>> 	. Kept the logic in pci_raw_set_power_state
>>> 	. Changed the ASPM enabling logic
>>> 	. Modified the text that describes the problem
>>>
>>> v1	: http://marc.info/?l=linux-pci&m=130013164703283&w=2
>>>
>>> The assumption made in commit 41cd766b065970ff6f6c89dd1cf55fa706c84a3d
>>> (PCI: Don't enable aspm before drivers have had a chance to veto it)
>> that
>>> pci_enable_device() will result in re-configuring ASPM when
>> aspm_policy is
>>> POWERSAVE is no longer valid.  This is due to commit
>>> 97c145f7c87453cec90e91238fba5fe2c1561b32 (PCI: read current power
>> state
>>> at enable time) which resets dev->current_state to D0. This makes the
>>> equality check (below) become true, so pcie_aspm_pm_state_change()
>> never
>>> gets called.
>>> ./drivers/pci/pci.c: pci_raw_set_pci_power_state()
>>> 546         /* Check if we're already there */
>>> 547         if (dev->current_state == state)
>>> 548                 return 0;
>>>
>>> So OSPM doesnn't configure the PCIe links for ASPM.
>>>
>>> The patch below does the following:
>>> At the end of each Root Bridge scan make a call to configure ASPM when
>> the
>>> ASPM policy is set to "powersave" mode. Note that if a previous pass
>> had
>>> completed the configuration for all devices under that Bridge then the
>>> configuration will not take place again because
>> pcie_config_aspm_link()
>>> checks to see if the link is already in the requested state.
>>> We won't reconfigure ASPM when _OSC control is not granted.
>>
>> Which _OSC controls do we need for configuring ASPM?
>
> There is no _OSC Control bit for ASPM. However, we expect the BIOS to
> support _OSC for a Root Bridge that originates a PCIe hierarchy. If this
> is not the case - would it be okay to disable ASPM also?
>
> Commit 852972acff8f10f3a15679be2059bb94916cba5d (ACPI: Disable ASPM if the
> Platform won't provide _OSC control for PCIe) describes the above scenario.
>
> To quote from there:
> The PCI SIG documentation for the _OSC OS/firmware handshaking interface
> states:
>
> "If the _OSC control method is absent from the scope of a host bridge
> device, then the operating system must not enable or attempt to use any
> features defined in this section for the hierarchy originated by the host
> bridge."
>
> The obvious interpretation of this is that the OS should not attempt to use
> PCIe hotplug, PME or AER - however, the specification also notes that an
> _OSC method is *required* for PCIe hierarchies, and experimental validation
> with An Alternative OS indicates that it doesn't use any PCIe functionality
> if the _OSC method is missing. That arguably means we shouldn't be using
> MSI or extended config space, but right now our problems seem to be limited
> to vendors being surprised when ASPM gets enabled on machines when other
> OSs refuse to do so. So, for now, let's just disable ASPM if the _OSC
> method doesn't exist or refuses to hand over PCIe capability control.
>

I understood. Thank you for clarification.

Regards,
Kenji Kaneshige

--
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/