mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Huang Ying <ying.huang@intel.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: huang ying <huang.ying.caritas@gmail.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] x86: make 64bit efi to use ioremap_cache for efi_ioremap
Date: Mon, 06 Oct 2008 09:47:50 +0800	[thread overview]
Message-ID: <1223257670.5872.11.camel@yhuang-dev.sh.intel.com> (raw)
In-Reply-To: <20081005100444.GG29909@elte.hu>

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Sun, 2008-10-05 at 12:04 +0200, Ingo Molnar wrote:
> * huang ying <huang.ying.caritas@gmail.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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-10-06  1:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-04  6:23 Yinghai Lu
2008-10-04  8:46 ` Ingo Molnar
2008-10-04  9:35 ` huang ying
2008-10-04 17:44   ` Yinghai Lu
2008-10-05  8:56     ` huang ying
2008-10-05 10:04       ` Ingo Molnar
2008-10-06  1:47         ` Huang Ying [this message]
2008-10-05 18:04       ` Yinghai Lu
2008-10-06  1:50         ` Huang Ying
2008-12-11 20:41 Jonathan Barkelew

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1223257670.5872.11.camel@yhuang-dev.sh.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome