[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1223257670.5872.11.camel@yhuang-dev.sh.intel.com>
Date: Mon, 06 Oct 2008 09:47:50 +0800
From: Huang Ying <ying.huang@...el.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: huang ying <huang.ying.caritas@...il.com>,
Yinghai Lu <yinghai@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] x86: make 64bit efi to use ioremap_cache for
efi_ioremap
On Sun, 2008-10-05 at 12:04 +0200, Ingo Molnar wrote:
> * huang ying <huang.ying.caritas@...il.com> wrote:
[...]
> > 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.
EFI runtime memory area will be E820_RESERVED in e820 map and
EFI_RUNTIME_SERVICES_CODE/DATA in EFI memory map. In general they will
be mapped directly.
ioremap() should not used here, because for kexec to work, EFI runtime
memory area should be mapped to same virtual address across reboot.
Best Regards,
Huang Ying
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists