[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F471651.3080609@zytor.com>
Date: Thu, 23 Feb 2012 20:47:13 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Yinghai Lu <yinghai@...nel.org>
CC: matt.fleming@...el.com, mingo@...hat.com, mjg@...hat.com,
linux-kernel@...r.kernel.org, keithp@...thp.com,
rui.zhang@...el.com, huang.ying.caritas@...il.com,
stable@...r.kernel.org, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix CONFIG_X86_32
oops
On 02/23/2012 02:36 AM, Yinghai Lu wrote:
> On Wed, Feb 22, 2012 at 7:32 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> On 02/22/2012 06:20 PM, Yinghai Lu wrote:
>>>
>>> Why is MAXMEM used here?
>>>
>>> EFI reserved area could be above 4G?
>>>
>>> if that is the case, you will map all mmio hole below 4g.
>>>
>>
>> OK, dropping this patch for now, at least from -urgent.
>>
>> We really need to restrict the memory types we map, at least without
>> ioremap() called on them. In theory, on x86-64, we could have a
>> dedicated "1:1" address for each physical address, but there is no good
>> reason we should ever map memory types other than RAM, ACPI and EFI by
>> default -- with the possible exception of the low 1 MiB legacy area.
>
> please check attach patch for tip/efi branch.
That doesn't do anything like what I noted above.
We should get rid of dependencies on legacy PC memory layouts, not add
more hacks. What is so hard about "when we create the initial mappings,
only create for RAM/ACPI/EFI regions" (if we even need to do so for
ACPI, I think ACPI might use ioremap() already)?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
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