From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jacob Shin <jacob.shin@amd.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Tejun Heo <tj@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit
Date: Fri, 05 Oct 2012 17:36:05 -0700 [thread overview]
Message-ID: <506F7CF5.2070904@zytor.com> (raw)
In-Reply-To: <87zk40mokt.fsf@xmission.com>
On 10/05/2012 05:28 PM, Eric W. Biederman wrote:
>>
>> Seriously, any case where we can't load anywhere in physical ram on x86-64 is a
>> bug. i386 is another matter.
>
> As I recall there are data structures like the IDT that only have a
> 32bit base address.
>
Not true. The only one I know of is memory for the trampoline which has
to be below 1M. The < 1M space is already handled specially for good
reason.
> According to the bzImage header we don't support ramdisks above 4G.
> I think we also have a 32bit address for the kernel command line
> in the bzImage header.
There are pointers in the bzImage header, that is true. We can fix that
problem, though, at least for entry via the 64-bit entry point.
> In the case of kdump in particular there is a need for DMAable
> memory and in general that means memory below 4G. So as long
> as we only support one memory extent for kdump it makes sense
> for that segment to be below 4G.
"In general" meaning "no iotlb"? In that case you have some unknown
address space restriction which may or may not be 4G...
> For a normal x86_64 kernel which gets to use most of the memory it
> definitely should be loadable anywhere in memory.
Yes. We should fix problems, like the limitations in the boot_params
structure.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2012-10-06 0:36 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-30 7:57 [PATCH -v4 00/13] x86, mm: init_memory_mapping cleanup Yinghai Lu
2012-09-30 7:57 ` [PATCH 01/13] x86, mm: Add global page_size_mask and probe one time only Yinghai Lu
2012-09-30 7:57 ` [PATCH 02/13] x86, mm: Split out split_mem_range from init_memory_mapping Yinghai Lu
2012-09-30 7:57 ` [PATCH 03/13] x86, mm: Move init_memory_mapping calling out of setup.c Yinghai Lu
2012-09-30 7:57 ` [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit Yinghai Lu
2012-10-01 11:00 ` Stefano Stabellini
2012-10-03 16:51 ` Jacob Shin
2012-10-03 18:34 ` H. Peter Anvin
2012-10-04 13:56 ` Konrad Rzeszutek Wilk
2012-10-04 21:52 ` H. Peter Anvin
2012-10-04 16:19 ` Yinghai Lu
2012-10-04 16:46 ` Konrad Rzeszutek Wilk
2012-10-04 21:29 ` Yinghai Lu
2012-10-05 21:04 ` Eric W. Biederman
2012-10-05 21:19 ` Yinghai Lu
2012-10-05 21:32 ` Eric W. Biederman
2012-10-05 21:37 ` Yinghai Lu
2012-10-05 21:41 ` Eric W. Biederman
2012-10-05 21:43 ` Yinghai Lu
2012-10-05 22:01 ` 896MB address limit (was: Re: [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit) Eric W. Biederman
2012-10-05 22:01 ` Eric W. Biederman
2012-10-06 0:18 ` [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit H. Peter Anvin
2012-10-06 0:45 ` Eric W. Biederman
2012-10-06 1:02 ` H. Peter Anvin
2012-10-06 0:17 ` H. Peter Anvin
2012-10-06 0:28 ` Eric W. Biederman
2012-10-06 0:36 ` H. Peter Anvin [this message]
2012-10-04 15:57 ` Yinghai Lu
2012-10-04 16:45 ` Konrad Rzeszutek Wilk
2012-10-04 21:21 ` Yinghai Lu
2012-10-04 21:40 ` Yinghai Lu
2012-10-04 21:41 ` H. Peter Anvin
2012-10-04 21:46 ` Yinghai Lu
2012-10-04 21:54 ` H. Peter Anvin
2012-10-05 7:46 ` Yinghai Lu
2012-10-05 11:27 ` Stefano Stabellini
2012-10-05 14:58 ` Yinghai Lu
2012-10-06 7:44 ` [PATCH 0/3] x86: pre mapping page table to make xen happy Yinghai Lu
2012-10-06 7:44 ` [PATCH 1/3] x86: get early page table from BRK Yinghai Lu
2012-10-08 12:09 ` Stefano Stabellini
2012-10-06 7:44 ` [PATCH 2/3] x86, mm: Don't clear page table if next range is ram Yinghai Lu
2012-10-09 15:46 ` Konrad Rzeszutek Wilk
2012-10-10 1:00 ` Yinghai Lu
2012-10-10 13:41 ` Konrad Rzeszutek Wilk
2012-10-10 14:43 ` Yinghai Lu
2012-10-06 7:44 ` [PATCH 3/3] x86, mm: Remove early_memremap workaround for page table accessing Yinghai Lu
2012-10-09 15:48 ` Konrad Rzeszutek Wilk
2012-10-08 6:36 ` [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit Yinghai Lu
2012-10-05 10:47 ` Stefano Stabellini
2012-09-30 7:57 ` [PATCH 05/13] x86, mm: Find early page table buffer altogether Yinghai Lu
2012-09-30 7:57 ` [PATCH 06/13] x86, mm: Separate out calculate_table_space_size() Yinghai Lu
2012-09-30 7:57 ` [PATCH 07/13] x86, mm: Move down two calculate_table_space_size down Yinghai Lu
2012-09-30 7:57 ` [PATCH 08/13] x86, mm: Set memblock initial limit to 1M Yinghai Lu
2012-09-30 7:57 ` [PATCH 09/13] x86: if kernel .text .data .bss are not marked as E820_RAM, complain and fix Yinghai Lu
2012-09-30 7:57 ` [PATCH 10/13] x86: Fixup code testing if a pfn is direct mapped Yinghai Lu
2012-09-30 7:57 ` [PATCH 11/13] x86: Only direct map addresses that are marked as E820_RAM Yinghai Lu
2012-09-30 7:57 ` [PATCH 12/13] x86/mm: calculate_table_space_size based on memory ranges that are being mapped Yinghai Lu
2012-09-30 7:57 ` [PATCH 13/13] x86, mm: Use func pointer to table size calculation and mapping Yinghai Lu
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=506F7CF5.2070904@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=jacob.shin@amd.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.