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: <20081005100444.GG29909@elte.hu>
Date:	Sun, 5 Oct 2008 12:04:44 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	huang ying <huang.ying.caritas@...il.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Huang Ying <ying.huang@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] x86: make 64bit efi to use ioremap_cache for
	efi_ioremap


* huang ying <huang.ying.caritas@...il.com> wrote:

> On Sun, Oct 5, 2008 at 1:44 AM, Yinghai Lu <yinghai@...nel.org> wrote:
> > On Sat, Oct 4, 2008 at 2:35 AM, huang ying <huang.ying.caritas@...il.com> wrote:
> [...]
> >> Using __va and efi_ioremap() here is to make EFI support compatible
> >> with kexec. Because EFI provide only efi_enter_virtual_mode(), no
> >> efi_leave_virtual_mode(), we should make EFI runtime memory area
> >> mapped to same virtual memory area in original kernel and kexeced
> >> kernel, so that the EFI runtime services can be used in kexeced
> >> kernel.
> >
> > so need to make efi range all under direct-mapping like E820-RAM?
> 
> Some EFI runtime range is just some RAM area used by EFI runtime 
> services, they can be direct-mapped. Some EFI runtime range may be IO 
> MEM range used by EFI runtime services, it is possible that these IO 
> MEM range can not be direct-mapped. So I implement efi_ioremap() to 
> deal with them.

hm, but in the "some RAM area" case, that area should not be listed in 
the e820 map (or any EFI memory map), and hence it should never be 
mapped directly. I.e. you should be able to just standardize on 
ioremap() and have no parallel facility for this.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ