linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, Suresh Siddha <suresh.b.siddha@intel.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Jens Axboe <jens.axboe@oracle.com>,
	Jack Steiner <steiner@sgi.com>,
	LKML <linux-kernel@vger.kernel.org>,
	jkosina@novell.com
Subject: Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if 	add_efi_memmap specified.
Date: Wed, 26 May 2010 10:42:48 -0700	[thread overview]
Message-ID: <4BFD5D98.6090408@sgi.com> (raw)
In-Reply-To: <AANLkTilNXcS_KQTQ4ZwDt8RQqSrlWUH2R5W87g0vI4xG@mail.gmail.com>



Yinghai Lu wrote:
> On Tue, May 25, 2010 at 3:46 PM, Mike Travis <travis@sgi.com> wrote:
>>
>> H. Peter Anvin wrote:
>>> On 05/25/2010 03:34 PM, Mike Travis wrote:
>>>> H. Peter Anvin wrote:
>>>>> On 05/13/2010 02:55 PM, Mike Travis wrote:
>>>>>> I saw that too, and wondered why e820_saved did not
>>>>>> have the extra entries.   The comment indicates it
>>>>>> should.
>>>>>>
>>>>>> I'm on the system tonight and will investigate this
>>>>>> further.
>>>>>>
>>>>> e820_saved lacks the extra entries because they aren't being passed in
>>>>> from the bootloader, as they should, and instead you're using
>>>>> add_efi_memmap which is, as far as the kernel is concerned, a post-boot
>>>>> modification.
>>>>>
>>>>> That being said, add_efi_memmap does come from the firmware, and as such
>>>>> it would be legitimate for it to add them to e820_saved.
>>>>>
>>>>>        -hpa
>>>> Did this last patch meet expectations?
>>>>
>>>> http://marc.info/?l=linux-kernel&m=127474230623061&w=4
>>>>
>>> I'm concerned about calling sanitize_e820_map() on e820_saved; it is
>>> supposed to reflect the raw data as reported by the source, and
>>> sanitizing it would corrupt that.
>>>
>>>        -hpa
>> I wondered about that. Sanitize seems to remove adjacent
>> entries, etc. making the map smaller, but I couldn't detect
>> any real differences (though admittedly I didn't do a byte
>> by byte comparison.)
>>
>> But I'll submit another with that call removed.
> 
> can you use updated boot loader instead?
> 
> Also we should drop add_efi_memmap if possible.
> 
> YH

I'm open for suggestions on how to improve this, but we are shipping
systems very soon and I don't think we'll get any other change into
the system until the next update.

Thanks,
Mike

  reply	other threads:[~2010-05-26 17:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-12 18:10 [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmap specified Mike Travis
2010-05-12 18:55 ` H. Peter Anvin
2010-05-12 20:19   ` Yinghai
2010-05-12 21:02     ` Mike Travis
2010-05-13 21:18       ` Mike Travis
2010-05-13 21:48         ` Yinghai
2010-05-13 21:55           ` Mike Travis
2010-05-13 22:46             ` H. Peter Anvin
2010-05-24 23:04               ` [Patch 1/1] x86 efi: insert add_efi_memmap entries into both e820 maps Mike Travis
2010-05-25 22:34               ` [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmap specified Mike Travis
2010-05-25 22:41                 ` H. Peter Anvin
2010-05-25 22:46                   ` Mike Travis
2010-05-25 22:49                     ` H. Peter Anvin
2010-05-26 17:39                     ` Yinghai Lu
2010-05-26 17:42                       ` Mike Travis [this message]
2010-05-26 18:22                         ` H. Peter Anvin
2010-05-26 18:47                           ` Mike Travis
2010-05-26 19:04                             ` H. Peter Anvin
2010-05-26 19:09                               ` Mike Travis
2010-05-26 20:10                                 ` H. Peter Anvin
2010-05-25 22:59                   ` [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmap specified v2 Mike Travis

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=4BFD5D98.6090408@sgi.com \
    --to=travis@sgi.com \
    --cc=hpa@zytor.com \
    --cc=jens.axboe@oracle.com \
    --cc=jkosina@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=steiner@sgi.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).