From: Huang Ying <ying.huang@intel.com>
To: Paul Mackerras <paulus@samba.org>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-tip-commits@vger.kernel.org"
<linux-tip-commits@vger.kernel.org>
Subject: Re: [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
Date: Tue, 04 Aug 2009 10:04:15 +0800 [thread overview]
Message-ID: <1249351455.24238.52.camel@yhuang-dev.sh.intel.com> (raw)
In-Reply-To: <19063.37940.634.400042@cargo.ozlabs.ibm.com>
On Tue, 2009-08-04 at 09:51 +0800, Paul Mackerras wrote:
> Huang Ying writes:
>
> > This patch does not really fix the issue. __cpa_process_fault will warn
> > if target memory area is beyond max_pfn_mapped. EFI runtime RAM area
> > beyond max_pfn_mapped will trigger the warning too.
>
> I think we already have that situation on that MacBook, and there is
> no warning. From dmesg:
>
> [ 0.000000] EFI: mem190: type=9, attr=0xf, range=[0x000000007fedf000-0x000000007feef000) (0MB)
> [ 0.000000] EFI: mem191: type=7, attr=0xf, range=[0x000000007feef000-0x000000007fef9000) (0MB)
> [ 0.000000] EFI: mem192: type=0, attr=0xf, range=[0x000000007fef9000-0x000000007feff000) (0MB)
> [ 0.000000] EFI: mem193: type=6, attr=0x800000000000000f, range=[0x000000007feff000-0x000000007ff00000) (0MB)
> ...
> [ 0.000000] last_pfn = 0x7fef9 max_arch_pfn = 0x400000000
> ...
> [ 0.000000] initial memory mapped : 0 - 20000000
> [ 0.000000] init_memory_mapping: 0000000000000000-000000007fef9000
> [ 0.000000] 0000000000 - 007fe00000 page 2M
> [ 0.000000] 007fe00000 - 007fef9000 page 4k
> [ 0.000000] kernel direct mapping tables up to 7fef9000 @ 8000-c000
> ...
> [ 0.001920] init_memory_mapping: 000000007feff000-000000007ff00000
> [ 0.001926] 007feff000 - 007ff00000 page 4k
>
> So the initial mapping ends at 0x7fef9000, and I believe that
> max_pfn_mapped is 0x7fef9, and then EFI asks for pfn 0x7feff to be
> mapped. But I freely admit this is not my area of expertise. This
> machine has 2GB of RAM, by the way.
If you specify "mem=<xxx>m" to a small value in kernel command line, I
think the kernel warning will appear again. Because some EFI runtime
memory area may be beyond max_pfn_mapped.
> > To fix the issue. I think we can loose the restriction of
> > __cpa_process_fault a little. Add a global variable max_pfn, which is
> > max pfn of all memory type (including RAM, RESERVED, etc, mapped or
> > unmapped), and __cpa_process_fault warns for memory area beyond max_pfn
> > only.
>
> It seemed cleaner to me to use ioremap() on areas that we are told are
> MMIO. Why would it be better to use init_memory_mapping for those
> areas?
I prefer init_memory_mapping because it is more compatible with KEXEC
support (not done yet). Because EFI runtime memory area should be mapped
in exactly same position in original and kexeced kernel.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2009-08-04 2:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-03 12:38 [PATCH] " Paul Mackerras
2009-08-03 17:12 ` [tip:x86/urgent] " tip-bot for Paul Mackerras
2009-08-04 1:20 ` Huang Ying
2009-08-04 1:51 ` Paul Mackerras
2009-08-04 2:04 ` Huang Ying [this message]
2009-08-03 21:47 ` tip-bot for Paul Mackerras
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=1249351455.24238.52.camel@yhuang-dev.sh.intel.com \
--to=ying.huang@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®