On 06/27/17 at 08:39pm, Baoquan He wrote:
> People complained that crashkernel high doesn't work when kaslr code
> compiled in but add 'nokaslr' to diable it. Kexec has the same
> phenomenon.
This is a regression, with 4.12* kernel kexec reboot fails always on
my desktop pc now without kaslr being
Commit-ID: 792ef14df5c585c19b2831673a077504a09e5203
Gitweb: http://git.kernel.org/tip/792ef14df5c585c19b2831673a077504a09e5203
Author: Dave Young
AuthorDate: Fri, 9 Jun 2017 08:45:58 +
Committer: Ingo Molnar
CommitDate: Fri, 9 Jun 2017 14:50:11 +0200
efi: Fix boot panic because of
o kill the idle
task!
Fixes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
Reported-by: Maniaxx
Signed-off-by: Dave Young
---
v1->v2: Ard: move EFI_MEMMAP checking out and improve the patchlog.
drivers/firmware/efi/efi-bgrt.c | 26 +-
1 file ch
On 06/09/17 at 10:29am, Dave Young wrote:
> On 06/09/17 at 10:17am, Xunlei Pang wrote:
> > S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
> > is now defined as follows:
> > typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
> > It was changed by th
On 06/08/17 at 03:51pm, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young wrote:
> > Maniaxx reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a uefi vm)
> > There are also a bug in bug
rid of all the old KEXEC_NOTE_BYTES stuff, and
> renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.
>
> Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code
> under CONFIG_CRASH_CORE")
> Cc: Dave Young
> Cc: Dave Anderson
> Cc: Hari Bathini
&
On 06/08/17 at 10:02am, Ard Biesheuvel wrote:
> On 8 June 2017 at 05:32, Dave Young wrote:
> > Maniaxx reported kernel boot panic similar to
> > below:
> > (emulated the panic with using same invalid phys addr in a uefi vm)
> > There are also a bug in bug
, Dave Young wrote:
> Maniaxx reported kernel boot panic similar to
> below:
> (emulated the panic with using same invalid phys addr in a uefi vm)
> There are also a bug in bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=195633
>
> This happens after below
I BGRT init code to early init code
Reported-by: Maniaxx
Signed-off-by: Dave Young
---
drivers/firmware/efi/efi-bgrt.c | 29 +
1 file changed, 29 insertions(+)
--- linux.orig/drivers/firmware/efi/efi-bgrt.c
+++ linux/drivers/firmware/efi/efi-bgrt.c
@@ -27,6 +27,31 @@
Commit-ID: 7425826f4f7ac60f2538b06a7f0a5d1006405159
Gitweb: http://git.kernel.org/tip/7425826f4f7ac60f2538b06a7f0a5d1006405159
Author: Dave Young
AuthorDate: Fri, 26 May 2017 12:36:51 +0100
Committer: Ingo Molnar
CommitDate: Sun, 28 May 2017 11:06:17 +0200
efi/bgrt: Skip efi_bgrt_init
On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> > Provide support so that kexec can be used to boot a kernel when SME is
> > enabled.
> >
> > Support is needed to allocate pages for kexec without encryption. This
> > is needed in order to be able to re
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-sp
ct mapping to build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave Young
Although I put some effort on debugging the problem, the patch should
be your credit, also I'm not familiar
Add Takahiro and Pratyush, they should be able to review the arm64 part.
On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used f
ct mapping to build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave Young
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. P
gt; else is mapped at the virtual address we allocated for runtime service
> regions in the initial boot] - Matt Fleming
>
> Since kexec was never intended to work with efi=old_map, disable
> runtime services in kexec if booted with efi=old_map, so that we don't
> panic.
>
On 05/15/17 at 02:23pm, Matt Fleming wrote:
> (Pulling in Dave, Mr. Kexec on EFI)
>
> On Mon, 08 May, at 12:25:23PM, Sai Praneeth Prakhya wrote:
> > From: Sai Praneeth
> >
> > Booting kexec kernel with "efi=old_map" in kernel command line hits
> > kernel panic as shown below.
> >
> > [0.001
1
---[ end trace f68728a0d3053b52 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Signed-off-by: Dave Young
Tested-by: Sab
On 05/15/17 at 01:10pm, Sabrina Dubroca wrote:
> 2017-05-15, 16:37:40 +0800, Dave Young wrote:
> > Hi,
> >
> > Thanks for the report.
> > On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> > >
Hi,
Thanks for the report.
On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> > From: Dave Young
> >
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through membl
On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
&g
Correct Vivek's email address
On 04/28/17 at 01:19pm, Dave Young wrote:
> Vivek, can you help to give some comments about the locate hole isssue
> in kexec_file?
>
> On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> > Thiago,
> >
> > Thank you for the comment.
Vivek, can you help to give some comments about the locate hole isssue
in kexec_file?
On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> Thiago,
>
> Thank you for the comment.
>
> On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > Am Mittwoch, 26. April 2017
Hi AKASHI
On 04/26/17 at 05:22pm, AKASHI Takahiro wrote:
> The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at
> the first memory region that has enough space for requested size even if
> some of higher regions may also have.
> This behavior is not consistent with locate_hole(h
On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> >
> > A new directory will be created:
> > /sys/kernel/mm/sme/
> >
> > And two entries within t
Hi Xunlei,
On 04/27/17 at 01:25pm, Xunlei Pang wrote:
> On 04/27/2017 at 11:06 AM, Dave Young wrote:
> > [snip]
> >>>>>
> >>>>> static int __init crash_save_vmcoreinfo_init(void)
> >>>>> {
> >>>>> + /* One
[snip]
> >>>
> >>> static int __init crash_save_vmcoreinfo_init(void)
> >>> {
> >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
> >> Can we add a comment in the VMCOREINFO_BYTES header file about the one
> >> page assumption?
> >>
> >> Or just define the VMCOREINFO_BY
[snip]
> >> index 43cdb00..a29e9ad 100644
> >> --- a/kernel/crash_core.c
> >> +++ b/kernel/crash_core.c
> >> @@ -15,9 +15,12 @@
> >>
> >> /* vmcoreinfo stuff */
> >> static unsigned char *vmcoreinfo_data;
> >> -size_t vmcoreinfo_size;
> >> +static size_t vmcoreinfo_size;
> >> u32 *vmcoreinfo_n
On 04/26/17 at 03:28pm, Dave Young wrote:
> On 04/26/17 at 08:22am, Ingo Molnar wrote:
> >
> > * Yinghai Lu wrote:
> >
> > > For x86 with recent kernel after
> > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > > c
On 04/26/17 at 08:22am, Ingo Molnar wrote:
>
> * Yinghai Lu wrote:
>
> > For x86 with recent kernel after
> > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem.
> >
> > So here, we add handling for that too.
Add ia64i list, and s390 list although Michael has tested it
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like t
, fmt, args);
> va_end(args);
>
> - r = min(r, vmcoreinfo_max_size - vmcoreinfo_size);
> + r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>
> memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
>
> --
> 1.8.3.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Reviewed-by: Dave Young
Thanks
Dave
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
> it has the risk of being modified by some wrong code during system
> is running.
>
> As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
> when using "crash", "mak
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first signature
On 04/07/17 at 04:28am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote:
> > On 04/07/17 at 08:07am, David Howells wrote:
> > > Dave Young wrote:
> > >
> > > > > > > + /* Don't permit images to be lo
On 04/07/17 at 03:45am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 14:19 +0800, Dave Young wrote:
> > On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> > > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > > > On 04/05/17 at 09:15pm, David Howells wrot
On 04/07/17 at 08:07am, David Howells wrote:
> Dave Young wrote:
>
> > > > > + /* Don't permit images to be loaded into trusted kernels if
> > > > > we're not
> > > > > + * going to verify the signature on them
> > >
On 04/07/17 at 08:05am, David Howells wrote:
> Dave Young wrote:
>
> > > > This option allows userspace to pass the RSDP address to the kernel,
> > > > which
> > > > makes it possible for a user to circumvent any restrictions imposed on
> >
On 04/06/17 at 09:43pm, Rafael J. Wysocki wrote:
> On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote:
> > From: Josh Boyer
> >
> > This option allows userspace to pass the RSDP address to the kernel, which
> > makes it possible for a user to circumvent any restrictions imposed on
> > loading m
On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > On 04/05/17 at 09:15pm, David Howells wrote:
> > > From: Chun-Yi Lee
> > >
> > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
&g
>* Verify we have a legal set of flags
>* This leaves us room for future extensions.
>*/
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
turn -EPERM;
> +
> /* Make sure we have a legal set of flags */
> if (flags != (flags & KEXEC_FILE_FLAGS))
> return -EINVAL;
>
>
> _______
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
On 04/04/17 at 02:37pm, Matt Fleming wrote:
> On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
> >
> > Matt, I'm fine if you prefer to capture the range checking errors.
> > Would you like me to post it or just you send it out?
>
> Can you please send out the
ffef - fffe (=64 GB) EFI region mapping space
> > EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END,
> > Here EFI_VA_START = -4G, and EFI_VA_END = -64G.
> >
> > Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
On 03/24/17 at 04:34pm, Baoquan He wrote:
> On 03/24/17 at 09:08am, Ingo Molnar wrote:
> > > Cc: #4.8+
> > > Signed-off-by: Baoquan He
> > > Acked-by: Dave Young
> > > Reviewed-by: Bhupesh Sharma
> > > Acked-by: Thomas Garnier
> > >
This should also cc linux-efi
On 03/24/17 at 10:29am, Dave Young wrote:
> Hi, Baoquan
>
> On 03/23/17 at 11:27am, Baoquan He wrote:
> > Currently KASLR is enabled on three regions: the direct mapping of physical
> > memory, vamlloc and vmemmap. However EFI region is als
n mapping space
> EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END
> Here EFI_VA_START = -4G, and EFI_VA_END = -64G
>
> Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
>
> Cc: #4.8+
> Signed-off-by: Baoquan He
> Acked-by: Dave
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> >
On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
> Dave Young writes:
>
> > On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> >> Xunlei Pang writes:
> >>
> >> > As Eric said,
> >> > "what we need to do is move the variable vmcoreinf
On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
> > As Eric said,
> > "what we need to do is move the variable vmcoreinfo_note out
> > of the kernel's .bss section. And modify the code to regenerate
> > and keep this information in something like the control page.
> >
>
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup()
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you ma
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is
> > not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> >
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the r
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, but the r
On 03/09/17 at 12:53pm, Ard Biesheuvel wrote:
> On 9 March 2017 at 10:54, Omar Sandoval wrote:
> > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> >> Add efi/kexec list.
> >>
> >> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> >
> > [
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm: swapper
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0
Hi,
On 03/08/17 at 04:45pm, Baoquan He wrote:
> Forgot cc to Boris, add him.
>
> On 03/08/17 at 04:18pm, Dave Young wrote:
> > On 03/08/17 at 03:47pm, Baoquan He wrote:
> > > EFI allocate runtime services regions down from EFI_VA_START, -4G.
> > &g
On 03/08/17 at 11:50am, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote:
> > All right, I will just update the code comment. Just back ported kaslr
> > to our OS product, people reviewed and found the upper boundary of kaslr
> > mm region is EFI_VA_START, that's
> IS_ENABLED(CONFIG_EFI)) &&
>vaddr_end >= __START_KERNEL_map);
> --
> 2.5.5
>
Acked-by: Dave Young
Thanks
Dave
On 03/08/17 at 03:47pm, Baoquan He wrote:
> EFI allocate runtime services regions down from EFI_VA_START, -4G.
> It should be top-down handling.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/platform/efi/efi_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86
On 03/06/17 at 11:58am, Tom Lendacky wrote:
> On 3/1/2017 3:25 AM, Dave Young wrote:
> > Hi Tom,
>
> Hi Dave,
>
> >
> > On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, F
50,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data,
> int *nr)
> *nr = 0;
> while (pa_data) {
> *nr += 1;
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
> if (!data) {
> ret = -ENOMEM;
> goto out;
> }
> pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
> }
>
> out:
>
It would be better that these cleanup patches are sent separately.
Acked-by: Dave Young
Thanks
Dave
On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data. This simplifies the code and will
> make the appropriate decision as to whether a RAM remapping can be done
> or if a fallback to ioremap_cache() is needed (which includes checking
> PageHighMem).
>
> Signed-off-b
On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
>
Add kexec list..
On 03/01/17 at 05:25pm, Dave Young wrote:
> Hi Tom,
>
> On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > > Provide
Hi Tom,
On 02/17/17 at 10:43am, Tom Lendacky wrote:
> On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote:
> > > Provide support so that kexec can be used to boot a kernel when SME is
> > > enabled.
> >
> > Is the point of kexec and
Hi Tom,
On 02/16/17 at 09:41am, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
On 01/27/17 at 05:03pm, Ard Biesheuvel wrote:
> On 16 January 2017 at 02:45, Dave Young wrote:
> > Hi,
> >
> > Here the the update of the series for moving bgrt init code to early init.
> >
> > Main changes is:
> > - Move the 1st patch to the last because
Commit-ID: 22c091d02a5422d2825a4fb1af71e5a62f9e4d0f
Gitweb: http://git.kernel.org/tip/22c091d02a5422d2825a4fb1af71e5a62f9e4d0f
Author: Dave Young
AuthorDate: Tue, 31 Jan 2017 13:21:41 +
Committer: Ingo Molnar
CommitDate: Wed, 1 Feb 2017 08:45:46 +0100
efi/x86: Add debug code to
Commit-ID: 7b0a911478c74ca02581d496f732c10e811e894f
Gitweb: http://git.kernel.org/tip/7b0a911478c74ca02581d496f732c10e811e894f
Author: Dave Young
AuthorDate: Tue, 31 Jan 2017 13:21:40 +
Committer: Ingo Molnar
CommitDate: Wed, 1 Feb 2017 08:45:46 +0100
efi/x86: Move the EFI BGRT
On 01/19/17 at 12:48pm, Ard Biesheuvel wrote:
> On 18 January 2017 at 19:24, Bhupesh Sharma wrote:
> > On Wed, Jan 18, 2017 at 7:30 PM, Ard Biesheuvel
> > wrote:
> >> On 18 January 2017 at 13:48, Dave Young wrote:
> >>> Before invoking the arch specific
Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:
> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
> not true and could be misleading, since 0 is a valid physical address.
I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if t
Hi, Xunlei
On 01/23/17 at 02:48pm, Xunlei Pang wrote:
> CRASH_KERNEL_ADDR_MAX has been missing for a long time,
> update it with more detailed explanation.
>
> Cc: Robert LeBlanc
> Cc: Baoquan He
> Signed-off-by: Xunlei Pang
> ---
> arch/x86/kernel/setup.c | 4 +++-
> 1 file changed, 3 insert
acpi table,
moving bgrt parsing to acpi early boot code can make sure efi_mem_reserve
in efi bgrt code still use memblock safely.
Signed-off-by: Dave Young
---
v1->v2: efi_bgrt_init: check table length first before copying bgrt table
error checking in drivers/acpi/bgrt.c
v2->v3: drop
On 01/18/17 at 07:06pm, Dave Young wrote:
> On 01/18/17 at 07:01pm, Dave Young wrote:
> > On 01/17/17 at 08:48pm, Nicolai Stange wrote:
> > > On Tue, Jan 17 2017, Ard Biesheuvel wrote:
> > >
> > > > On 16 January 2017 at 02:45, Dave Young wrote:
> &g
On 01/17/17 at 08:48pm, Nicolai Stange wrote:
> On Tue, Jan 17 2017, Ard Biesheuvel wrote:
>
> > On 16 January 2017 at 02:45, Dave Young wrote:
> >> efi_mem_reserve cares only about boot services regions, for making sure
> >> later efi_free_boot_services does
On 01/18/17 at 07:01pm, Dave Young wrote:
> On 01/17/17 at 08:48pm, Nicolai Stange wrote:
> > On Tue, Jan 17 2017, Ard Biesheuvel wrote:
> >
> > > On 16 January 2017 at 02:45, Dave Young wrote:
> > >> efi_mem_reserve cares only about boot services r
On 01/17/17 at 05:13pm, Ard Biesheuvel wrote:
> On 16 January 2017 at 02:45, Dave Young wrote:
> > efi_mem_reserve cares only about boot services regions, for making sure
> > later efi_free_boot_services does not free areas which are still useful,
> > such as bgrt image buf
On 01/17/17 at 05:10pm, Ard Biesheuvel wrote:
> On 16 January 2017 at 02:45, Dave Young wrote:
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through memblock.
> >
> > efi_bgrt_init will call efi_mem_reserve af
On 01/13/17 at 01:21pm, Nicolai Stange wrote:
> On Fri, Jan 13 2017, Dave Young wrote:
>
> > On 01/13/17 at 10:21am, Dave Young wrote:
> >> On 01/13/17 at 12:11am, Nicolai Stange wrote:
> >> > On Fri, Jan 13 2017, Dave Young wrote:
> >> >
> >
efi_mem_reserve cares only about boot services regions, for making sure
later efi_free_boot_services does not free areas which are still useful,
such as bgrt image buffer.
So add a new argument to efi_memmap_insert for this purpose.
Signed-off-by: Dave Young
---
v1->v2: only ch
It is not obvious if the reserved boot area are added correctly, add a
efi_print_memmap to print the new memmap.
Signed-off-by: Dave Young
Acked-by: Ard Biesheuvel
---
arch/x86/platform/efi/efi.c |5 +
1 file changed, 5 insertions(+)
--- linux-x86.orig/arch/x86/platform/efi/efi.c
Hi,
Here the the update of the series for moving bgrt init code to early init.
Main changes is:
- Move the 1st patch to the last because it does not block the 2nd patch
any more with Peter's patch to prune invlid memmap entries:
https://git.kernel.org/cgit/linux/kernel/git/efi/efi.git/commit/?h=n
Signed-off-by: Dave Young
---
v1->v2: move efi_print_memmap declaration to general header file
arch/x86/include/asm/efi.h|1 -
arch/x86/platform/efi/efi.c | 16
drivers/firmware/efi/memmap.c | 16
include/linux/efi.h |1 +
4 fi
acpi table,
moving bgrt parsing to acpi early boot code can make sure efi_mem_reserve
in efi bgrt code still use memblock safely.
Signed-off-by: Dave Young
---
v1->v2: efi_bgrt_init: check table length first before copying bgrt table
error checking in drivers/acpi/bgrt.c
arch/x86/ker
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 wrote:
> > > There are memory ranges like below when I testing early efi_mem_reserve:
>
On 01/13/17 at 10:21am, Dave Young wrote:
> On 01/13/17 at 12:11am, Nicolai Stange wrote:
> > On Fri, Jan 13 2017, Dave Young wrote:
> >
> > > On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> > >> On Thu, Jan 12 2017, Dave Young wrote:
> > &g
On 01/13/17 at 12:11am, Nicolai Stange wrote:
> On Fri, Jan 13 2017, Dave Young wrote:
>
> > On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> >> On Thu, Jan 12 2017, Dave Young wrote:
> >>
> >> > -void __init efi_bgrt_init(void)
> >> > +voi
On 01/12/17 at 01:08pm, Nicolai Stange wrote:
> On Thu, Jan 12 2017, Dave Young wrote:
>
> > Signed-off-by: Dave Young
> > ---
> > arch/x86/platform/efi/efi.c | 16
> > drivers/firmware/efi/memmap.c | 16
> > 2
On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> On Thu, Jan 12 2017, Dave Young wrote:
>
> > -void __init efi_bgrt_init(void)
> > +void __init efi_bgrt_init(struct acpi_table_header *table)
> > {
> > - acpi_status status;
> > void *image;
On 01/12/17 at 04:20pm, Ard Biesheuvel wrote:
> On 12 January 2017 at 09:41, Dave Young wrote:
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through memblock.
> >
> > efi_bgrt_init will call efi_mem_reserve af
On 01/12/17 at 12:15pm, Nicolai Stange wrote:
> Hi Dave,
>
> On Thu, Jan 12 2017, Dave Young wrote:
>
> > efi_mem_reserve cares only about boot services regions and maybe loader
> > areas.
> > So add a new argument to efi_memmap_insert for this
On 01/12/17 at 04:15pm, Ard Biesheuvel wrote:
> Hello Dave,
>
> On 12 January 2017 at 09:41, Dave Young wrote:
> > There are memory ranges like below when I testing early efi_mem_reserve:
> >
> > efi: mem62: [Reserved | | | | | | | |
[snip]
> --- linux-x86.orig/drivers/acpi/bgrt.c
> +++ linux-x86/drivers/acpi/bgrt.c
[snip]
>
> @@ -84,9 +85,17 @@ static int __init bgrt_init(void)
> {
> int ret;
>
> - if (!bgrt_image)
> + if (!bgrt_tab.image_address)
> return -ENODEV;
>
> + bgrt_image = mem
Hi,
Here is a patchset to move efi_bgrt_init to early code so that we can still use
memblock api.
Appreciated for comments and review.
Diffstat:
arch/x86/kernel/acpi/boot.c | 12 +++
arch/x86/platform/efi/efi-bgrt.c | 42
+--
arch/x86/platf
It is not obvious if the reserved boot area are added correctly, add a
efi_print_memmap to print the new memmap.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c |5 +
1 file changed, 5 insertions(+)
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++ linux-x86/arch/x86
301 - 400 of 1376 matches
Mail list logo
