linux-kernel - Re: [RFC] - Mapping ACPI tables as CACHED

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:	Fri, 23 Jul 2010 22:26:05 +0800
From:	ykzhao <yakui.zhao@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jack Steiner <steiner@....com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] - Mapping ACPI tables as CACHED

On Fri, 2010-07-23 at 15:23 +0800, Ingo Molnar wrote:
> * ykzhao <yakui.zhao@...el.com> wrote:
> 
> > From the above description maybe the E820_ACPI region can be mapped as 
> > cached. But this still depends on the BIOS. If the some shared data resides 
> > in the E820_ACPI region on some BIOS, maybe we can't map the E820_ACPI 
> > region as cached again.
> 
> I dont think we can do this safely unless some other OS (Windows) does it as 
> well. (the reason is that if some BIOS messes this up then it will cause nasty 
> bugs/problems only on Linux.)
> 

Yes. We can't map the corresponding ACPI region as cached under the
following case:
    >No E820_ACPI region is reported by BIOS. In such case the ACPI
table resides in the NVS region     

But if the BIOS can follow the spec and report the separated
E820_ACPI/E820_NVS region, maybe we can give a try to map the E820_ACPI
region as cached type. For example: the server machine.(The spec
describes the E820_ACPI region as reclaimed memory, which means that it
can be managed by OS after ACPI table is loaded).

Can we add a boot option to control whether the E820_ACPI region can be
mapped as cached type?

> But the benefits of caching are very clear and well measured by Jack, so we 
> want the feature. What we can do is to add an exception for 'known good' hw 
> vendors - i.e. something quite close to Jack's RFC patch, but implemented a 
> bit more cleanly:
> 
> Exposing x86_platform and e820 details to generic ACPI code isnt particularly 
> clean - there should be an ACPI accessor function for that or so: a new 
> acpi_table_can_be_cached(table) function or so.

Agree. The function of acpi_os_map_memory will also be used on IA64
platform. It seems more reasonable to use a wrapper function to check
whether the corresponding region can be mapped as cached type. 
> 
> In fact since __acpi_map_table(addr,size) is defined by architectures already, 
> this could be done purely within x86 code.
> 
> Thanks,
> 
> 	Ingo

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