From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: Re: [RFC] - Mapping ACPI tables as CACHED Date: Thu, 26 Aug 2010 13:47:55 -0400 (EDT) Message-ID: References: <20100722152220.GA18290@sgi.com> <20100817155939.GA4354@sgi.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from vms173011pub.verizon.net ([206.46.173.11]:41730 "EHLO vms173011pub.verizon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157Ab0HZRsR (ORCPT ); Thu, 26 Aug 2010 13:48:17 -0400 In-reply-to: <20100817155939.GA4354@sgi.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Jack Steiner Cc: mingo@elte.hu, tglx@linutronix.de, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org On Tue, 17 Aug 2010, Jack Steiner wrote: > On EFI-enabled systems (like UV), the ACPI tables are already mapped as > WB memory. This is done in the EFI function efi_enter_virtual_mode(). > > The E820_ACPI & E820_NVS regions will be mapped as WB memory if the BIOS > sets the WB attribute in the EFI memmap entry for the chunk of memory. > > The ACPI code in acpi_os_map_memory() is not currently aware of the EFI mapping > & currently maps the memory as UC. This seems like a bug. > > In order to prevent attribute aliasing, I think the ACPI mapping needs to > be consistent with the EFI mapping. Otherwise, we will have the OS > referencing the memory as UC at the same time BIOS is referencing it as WB. When would the firmware touch those tables after booting the OS? We once found a Toshiba laptop where the BIOS scribbles on the DSDT at run-time. We presumed from this that Windows must snapshot the tables at boot and run from a copy. We decided not to copy the tables, but to use them in-place. So we added a check for run-time corruption of the tables and we've seen it fire only on that one Toshiba box (which now boots with "acpi=copy_dsdt"). thanks, Len Brown, Intel Open Source Technology Center