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
| ||
|
Date: Sun, 5 Oct 2008 11:04:35 -0700 From: "Yinghai Lu" <yinghai@...nel.org> To: "huang ying" <huang.ying.caritas@...il.com> Cc: "Ingo Molnar" <mingo@...e.hu>, "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 On Sun, Oct 5, 2008 at 1:56 AM, 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. > i'm confused. so --- linux-2.6.orig/arch/x86/kernel/efi.c +++ linux-2.6/arch/x86/kernel/efi.c @@ -475,10 +475,7 @@ void __init efi_enter_virtual_mode(void) size = md->num_pages << EFI_PAGE_SHIFT; end = md->phys_addr + size; - if (PFN_UP(end) <= max_low_pfn_mapped) - va = __va(md->phys_addr); - else - va = efi_ioremap(md->phys_addr, size); + va = efi_ioremap(md->phys_addr, size); md->virt_addr = (u64) (unsigned long) va; should be ok. then how about use ioremap directly to replace fixed mapping in 64bit with efi_ioremap? YH -- 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