Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762891AbXIVG4a (ORCPT ); Sat, 22 Sep 2007 02:56:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757919AbXIVG4U (ORCPT ); Sat, 22 Sep 2007 02:56:20 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]:64622 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757836AbXIVG4T (ORCPT ); Sat, 22 Sep 2007 02:56:19 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DgMdY3J5im/rgr8ERB51KaRDoQ7tZEMOGglZQhAuaCU4RVL5hzWiU/HsByhqiYTOdrpulycXGVd8vmxfhfwhmlxBZoiPNbUQd69eXBYhCgpyHl3CqYKNjE0BQ/DkiutFCbA6BmQ61mHjNV/JuAEyUua6XYAB/7A3mppmZ/rzfLA= Message-ID: <86802c440709212356v498610cfo589b45a0bfc76dd6@mail.gmail.com> Date: Fri, 21 Sep 2007 23:56:18 -0700 From: "Yinghai Lu" To: "Andi Kleen" Subject: Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources Cc: hancockr@shaw.ca, rajesh.shah@intel.com, jbarnes@virtuousgeek.org, greg@kroah.com, patches@x86-64.org, linux-kernel@vger.kernel.org In-Reply-To: <86802c440709212349l3d968d1bgdc89e7c7415b54da@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709221231.836138000@suse.de> <20070921223207.7BBE71479D@wotan.suse.de> <86802c440709212349l3d968d1bgdc89e7c7415b54da@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2718 Lines: 58 On 9/21/07, Yinghai Lu wrote: > On 9/21/07, Andi Kleen wrote: > > > > From: Robert Hancock > > > > This path adds validation of the MMCONFIG table against the ACPI reserved > > motherboard resources. If the MMCONFIG table is found to be reserved in > > ACPI, we don't bother checking the E820 table. The PCI Express firmware > > spec apparently tells BIOS developers that reservation in ACPI is required > > and E820 reservation is optional, so checking against ACPI first makes > > sense. Many BIOSes don't reserve the MMCONFIG region in E820 even though > > it is perfectly functional, the existing check needlessly disables MMCONFIG > > in these cases. > > > > In order to do this, MMCONFIG setup has been split into two phases. If PCI > > configuration type 1 is not available then MMCONFIG is enabled early as > > before. Otherwise, it is enabled later after the ACPI interpreter is > > enabled, since we need to be able to execute control methods in order to > > check the ACPI reserved resources. Presently this is just triggered off > > the end of ACPI interpreter initialization. > > > > There are a few other behavioral changes here: > > > > - Validate all MMCONFIG configurations provided, not just the first one. > > > > - Validate the entire required length of each configuration according to > > the provided ending bus number is reserved, not just the minimum required > > allocation. > > > > - Validate that the area is reserved even if we read it from the chipset > > directly and not from the MCFG table. This catches the case where the > > BIOS didn't set the location properly in the chipset and has mapped it > > over other things it shouldn't have. > > > > This also cleans up the MMCONFIG initialization functions so that they > > simply do nothing if MMCONFIG is not compiled in. > > > > Based on an original patch by Rajesh Shah from Intel. > > > > [akpm@linux-foundation.org: many fixes and cleanups] > > Signed-off-by: Robert Hancock > > Signed-off-by: Andi Kleen > > Cc: Rajesh Shah > > Cc: Jesse Barnes > > Acked-by: Linus Torvalds > > Cc: Andi Kleen > > Cc: Greg KH > > Signed-off-by: Andrew Morton Also the titile is misleading: it is x86 instead of i386.. because it will affect x86_64 too. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/