From: Dave Young <dyoung@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Matt Fleming" <matt@codeblueprint.co.uk>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"Nicolai Stange" <nicstange@gmail.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Mika Penttilä" <mika.penttila@nextfour.com>,
bhsharma@redhat.com
Subject: Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas
Date: Fri, 13 Jan 2017 16:10:23 +0800 [thread overview]
Message-ID: <20170113081015.GA5328@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20170112211953.GA2709@dhcp-128-65.nay.redhat.com>
On 01/13/17 at 05:20am, Dave Young wrote:
> On 01/12/17 at 04:15pm, Ard Biesheuvel wrote:
> > Hello Dave,
> >
> > On 12 January 2017 at 09:41, Dave Young <dyoung@redhat.com> wrote:
> > > There are memory ranges like below when I testing early efi_mem_reserve:
> > >
> > > efi: mem62: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > > efi: mem63: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > > efi: mem64: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > > efi: mem65: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > > efi: mem66: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > > efi: mem67: [Reserved | | | | | | | | | | | | ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)
> > >
> >
> > Did you spot Peter's patch to prune invalid memmap entries?
> >
> > https://git.kernel.org/cgit/linux/kernel/git/efi/efi.git/commit/?h=next&id=b2a91a35445229
> >
> > I would expect this patch to no longer be necessary with that in place, no?
>
> Ard, good suggestion, I did not notice that patch, will try. Actually
> I'm not sure about fake_mem handling, if we can filter out the invalid
> ranges then it will be natural to drop this one after a test.
The commit works for me. I updated the series.
I addressed comments known, moved patch 1 to 4/4 with only boot service
(dropped loader areas checking), I plan to send them out next Monday
see if there are more comments.
If anyone who want to try them now, feel free to download from below url:
http://people.redhat.com/~ruyang/efi-bgrt/
Thanks
Dave
next prev parent reply other threads:[~2017-01-13 8:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 9:41 [PATCH 0/4] efi/x86: move efi bgrt init code to early init Dave Young
2017-01-12 9:41 ` [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas Dave Young
2017-01-12 11:15 ` Nicolai Stange
2017-01-12 21:29 ` Dave Young
2017-01-27 14:48 ` Matt Fleming
2017-01-27 17:04 ` Ard Biesheuvel
2017-01-27 22:13 ` Matt Fleming
2017-01-27 22:15 ` Ard Biesheuvel
2017-01-12 16:15 ` Ard Biesheuvel
2017-01-12 21:20 ` Dave Young
2017-01-13 8:10 ` Dave Young [this message]
2017-01-12 9:41 ` [PATCH 2/4] efi/x86: move efi bgrt init code to early init code Dave Young
2017-01-12 9:56 ` Dave Young
2017-01-12 11:54 ` Nicolai Stange
2017-01-12 21:39 ` Dave Young
2017-01-12 23:11 ` Nicolai Stange
2017-01-13 2:21 ` Dave Young
2017-01-13 3:04 ` Dave Young
2017-01-13 12:21 ` Nicolai Stange
2017-01-16 2:55 ` Dave Young
2017-01-12 16:20 ` Ard Biesheuvel
2017-01-12 21:33 ` Dave Young
2017-01-16 15:15 ` Bhupesh Sharma
2017-01-17 17:00 ` Ard Biesheuvel
2017-01-12 9:41 ` [PATCH 3/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c Dave Young
2017-01-12 12:08 ` Nicolai Stange
2017-01-12 21:40 ` Dave Young
2017-01-12 9:41 ` [PATCH 4/4] efi/x86: add debug code to print cooked memmap Dave Young
2017-01-12 16:18 ` Ard Biesheuvel
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=20170113081015.GA5328@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mika.penttila@nextfour.com \
--cc=mingo@kernel.org \
--cc=nicstange@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@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
all inboxes | Powered by JetHome®