All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.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:28:02 -0700	[thread overview]
Message-ID: <87zk40mokt.fsf@xmission.com> (raw)
In-Reply-To: <506F78A2.3050408@zytor.com> (H. Peter Anvin's message of "Fri, 05 Oct 2012 17:17:38 -0700")

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
>> Yinghai Lu <yinghai@kernel.org> writes:
>>
>>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>>>>> Is there a git commit that explains what the 'big range' problem is?
>>>>
>>>> At least on x86_64 this was recently tested and anywhere below 4G is
>>>> good, and there is a patch floating around somewhere to remove this
>>>> issue.
>>>
>>> patch for kernel or kexec-tools?
>>
>> kernel.
>>
>> The sgi guys needed a kdump kernel with 1G of ram to dump their all of
>> the memory on one of their crazy large machines and so investigated
>> this.
>>
>> Basically they found that a kdump kernel loaded anywhere < 4G worked,
>> the only change that was needed was to relaxy the 896M hard code.
>>
>> In one test they had a kdump kernel loaded above 2G.
>>
>
> 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.

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.

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.

For a normal x86_64 kernel which gets to use most of the memory it
definitely should be loadable anywhere in memory.

Eric

  reply	other threads:[~2012-10-06  0:28 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 [this message]
2012-10-06  0:36                       ` H. Peter Anvin
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=87zk40mokt.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.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.