linux-kernel - Re: [RFC PATCH 1/1] PCI: skip release and reallocation of io port resources

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: <4C33B883.6010206@kernel.org>
Date:	Tue, 06 Jul 2010 16:13:07 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
CC:	Ram Pai <linuxram@...ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	clemens@...isch.de
Subject: Re: [RFC PATCH 1/1] PCI: skip release and reallocation of io port
 resources

On 07/02/2010 02:35 PM, Jesse Barnes wrote:
> On Wed, 30 Jun 2010 16:59:49 -0700
> Ram Pai <linuxram@...ibm.com> wrote:
> 
>> On Wed, Jun 30, 2010 at 04:10:26PM -0700, Linus Torvalds wrote:
>>> On Wed, Jun 30, 2010 at 2:15 PM, Ram Pai <linuxram@...ibm.com> wrote:
>>>>       PCI: skip release and reallocation of io port resources
>>>
>>> Gaah. This still looks like just total ad-hoc hackery. The logic for
>>> it all seems very fragile, just a random case made up from the one
>>> failing issue. There's no underlying logic or design to it.
>>>
>>> I still think that we should just make people explicitly ask for a
>>> blank slate if the bios allocations don't work out. 
>>
>> and interactively allocate resource?
> 
> No I don't think we want to add any prompts to the kernel boot
> process. :)
> 
>>> Rather than trying
>>> to fix it up automatically, which has been a total rats nest of random
>>> crud.
>>
>> Can Yinghai Lu's patch 'pci=try=' be some temporary middle ground till
>> a more elaborate patch is found?
>>
>> His suggestion partly meets your suggestion. It does not automatically 
>> reassign unless the user explicitly asks for it. Hence should not
>> break any working systems, at the same time can handle system like 
>> mine.
> 
> pci=try just doesn't communicate much, it should be something like
> pci=override_bios and do as Linus suggests.

So you want to use pci=override_bios to reallocate all bios assigned resource include
peer root buses resources and pci bridge resource and pci devices BAR?

in that case, we may need to update
1. io apic related BAR to be consistent with io apic addr from MADT.
2. other ACPI related tables like return for _CRS...

or just change pci=try to pci=override_bios in my patch?

> 
> But we should continue to shoot for not ever having to use that option
> on normal systems.
> 

replacing legacy bios with linuxbios is cleanest way.

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