et;
> }
>
> @@ -250,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(*dat
tatic 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).
>
>
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).
>
>
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,
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:
> > > > Provi
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:
> > > > Provi
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/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
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
On 01/27/17 at 05:03pm, Ard Biesheuvel wrote:
> On 16 January 2017 at 02:45, Dave Young <dyo...@redhat.com> wrote:
> > Hi,
> >
> > Here the the update of the series for moving bgrt init code to early init.
> >
> > Main changes is:
> > - Move the 1s
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 <dyo...@redhat.com>
AuthorDate: Tue, 31 Jan 2017 13:21:41 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Wed, 1 Feb 2
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
Commit-ID: 7b0a911478c74ca02581d496f732c10e811e894f
Gitweb: http://git.kernel.org/tip/7b0a911478c74ca02581d496f732c10e811e894f
Author: Dave Young <dyo...@redhat.com>
AuthorDate: Tue, 31 Jan 2017 13:21:40 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Wed, 1 Feb 2
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 <bhsha...@redhat.com> wrote:
> > On Wed, Jan 18, 2017 at 7:30 PM, Ard Biesheuvel
> > <ard.biesheu...@linaro.org> wrote:
> >> On 18 January 2017 at 13:48, Dave Young <
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
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
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
> ---
>
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
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 <dyo...@redhat.com>
---
v1->v2: efi_bgrt_init: check table length first before copying bgrt table
error checking in drivers/ac
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 <dyo...@redhat.
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 <dyo...@redhat.com> wrote:
> >> efi_mem_reserve cares only about boot services regions, for making sure
> >> later efi_fr
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 <dyo...@redhat.com> wrote:
> > >> efi_mem_reserve cares only ab
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 <dyo...@redhat.com> 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,
> >
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 b
On 01/17/17 at 05:10pm, Ard Biesheuvel wrote:
> On 16 January 2017 at 02:45, Dave Young <dyo...@redhat.com> wrote:
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through memblock.
> >
> > efi_bgrt_init will c
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:
> >> >
> >
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 <dyo...@redhat.com>
---
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 <dyo...@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
arch/x86/platform/efi/efi.c |5 +
1 file changed,
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:
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:
Signed-off-by: Dave Young <dyo...@redhat.com>
---
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/li
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 <dyo...@redhat.com>
---
v1->v2: efi_bgrt_init: check table length first before copying bgrt table
error checking in drivers/ac
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 <dyo...@redhat.com> wrote:
> > > There are memory ranges like below when I testing early efi_mem_reserv
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 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/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 <dyo...@redhat.com>
> > ---
> > arch/x86/platform/efi/efi.c | 16
> > drivers/firmware/efi/memmap.c | 16 +
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 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 <dyo...@redhat.com> wrote:
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through memblock.
> >
> > efi_bgrt_init will c
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 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 <dyo...@redhat.com> wrote:
> > There are memory ranges like below when I testing early efi_mem_reserve:
> >
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 =
[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 =
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
+--
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
+--
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 <dyo...@redhat.com>
---
arch/x86/platform/efi/efi.c |5 +
1 file changed, 5 insertions(+)
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++
Signed-off-by: Dave Young <dyo...@redhat.com>
---
arch/x86/platform/efi/efi.c | 16
drivers/firmware/efi/memmap.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++ linux-x86/arch/x86/platfo
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
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 16
drivers/firmware/efi/memmap.c | 16
2 files changed, 16 insertions(+), 16 deletions(-)
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++ linux-x86/arch/x86/platform/efi/efi.c
@@ -210,22
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 <dyo...@redhat.com>
---
arch/x86/kernel/acpi/boot.c | 12 +++
arch/x86/platform/efi/efi-bgrt.c
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
---
arch/x86/kernel/acpi/boot.c | 12 +++
arch/x86/platform/efi/efi-bgrt.c | 42 +--
arch
.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
arch/x86/platform/efi/quirks.c |2 +-
drivers/firmware/efi/fake_mem.c |3 ++-
drivers/firmware/efi/memmap.c |8 +++-
include/linux/efi.h |4 ++--
4 files changed, 12 insertions(+), 5 deletions(-)
--- linux-x8
.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/quirks.c |2 +-
drivers/firmware/efi/fake_mem.c |3 ++-
drivers/firmware/efi/memmap.c |8 +++-
include/linux/efi.h |4 ++--
4 files changed, 12 insertions(+), 5 deletions(-)
--- linux-x86.orig/drivers/firmware
On 01/10/17 at 12:51pm, Matt Fleming wrote:
> On Tue, 10 Jan, at 08:37:35AM, Dave Young wrote:
> >
> > It is true that it depends on acpi init, I was wondering if bgrt parsing can
> > be moved to early acpi code. But anyway I'm not sure it is doable and
> > worth.
>
On 01/10/17 at 12:51pm, Matt Fleming wrote:
> On Tue, 10 Jan, at 08:37:35AM, Dave Young wrote:
> >
> > It is true that it depends on acpi init, I was wondering if bgrt parsing can
> > be moved to early acpi code. But anyway I'm not sure it is doable and
> > worth.
>
On 01/09/17 at 11:44am, Matt Fleming wrote:
> On Thu, 05 Jan, at 05:12:42PM, Dave Young wrote:
> > On 12/22/16 at 11:23am, Nicolai Stange wrote:
> > > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > > the given memory region through memblock.
&
On 01/09/17 at 11:44am, Matt Fleming wrote:
> On Thu, 05 Jan, at 05:12:42PM, Dave Young wrote:
> > On 12/22/16 at 11:23am, Nicolai Stange wrote:
> > > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > > the given memory region through memblock.
&
e unnecessary
> + */
> +void purgatory(void);
> +int verify_sha256_digest(void);
> +
> +extern unsigned long backup_dest;
> +extern unsigned long backup_src;
> +extern unsigned long backup_sz;
> +
> +struct sha_region {
> + unsigned long start;
> + unsigned long len;
> +};
> +
> +extern u8 sha256_digest[];
> +extern struct sha_region sha_regions[];
> +
> +#endif
> --
> 2.1.4
>
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
; Signed-off-by: Nicholas Mc Guire
> ---
>
> V2: after kbuild test robot reported a build failure
> removed incorrect declaration of copy_backup_region which is static
> anyway.
>
> V3: move it all into purgatory.h as fixing up the declarations in the .c
>
buf, , sizeof(note));
> - buf += (sizeof(note) + 3)/4;
> - memcpy(buf, name, note.n_namesz);
> - buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> - buf += (note.n_descsz + 3)/4;
> -
> - return buf;
> -}
> -
> -static void final_note(u32 *buf)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type = 0;
> - memcpy(buf, , sizeof(note));
> -}
> -
> void crash_save_cpu(struct pt_regs *regs, int cpu)
> {
> struct elf_prstatus prstatus;
>
It looks good to me. But better to have words from IA64 people as well.
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
buf += (sizeof(note) + 3)/4;
> - memcpy(buf, name, note.n_namesz);
> - buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> - buf += (note.n_descsz + 3)/4;
> -
> - return buf;
> -}
> -
> -static void final_note(u32 *buf)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type = 0;
> - memcpy(buf, , sizeof(note));
> -}
> -
> void crash_save_cpu(struct pt_regs *regs, int cpu)
> {
> struct elf_prstatus prstatus;
>
It looks good to me. But better to have words from IA64 people as well.
Acked-by: Dave Young
Thanks
Dave
| 445
>
> kernel/kexec_core.c| 404
> kernel/ksysfs.c|8 +
> kernel/printk/printk.c |6 -
> 9 files changed, 531 insertions(+), 463 deletions(-)
> create mode 100644 include/linux/crash_core.h
> create mode 100644 kernel/crash_core.c
>
[snip]
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
> kernel/kexec_core.c| 404
> kernel/ksysfs.c|8 +
> kernel/printk/printk.c |6 -
> 9 files changed, 531 insertions(+), 463 deletions(-)
> create mode 100644 include/linux/crash_core.h
> create mode 100644 kernel/crash_core.c
>
[snip]
Acked-by: Dave Young
Thanks
Dave
On 01/05/17 at 08:42am, Ingo Molnar wrote:
>
> * Nicolai Stange wrote:
>
> > Matt Fleming writes:
> >
> > > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> > >> So, after memblock is gone, allocations should be done through the
> > >>
On 01/05/17 at 08:42am, Ingo Molnar wrote:
>
> * Nicolai Stange wrote:
>
> > Matt Fleming writes:
> >
> > > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> > >> So, after memblock is gone, allocations should be done through the
> > >> "normal"
> > >> page allocator. Introduce a
On 12/22/16 at 11:23am, Nicolai Stange wrote:
> Before invoking the arch specific handler, efi_mem_reserve() reserves
> the given memory region through memblock.
>
> efi_mem_reserve() can get called after mm_init() though -- through
> efi_bgrt_init(), for example. After mm_init(), memblock is
On 12/22/16 at 11:23am, Nicolai Stange wrote:
> Before invoking the arch specific handler, efi_mem_reserve() reserves
> the given memory region through memblock.
>
> efi_mem_reserve() can get called after mm_init() though -- through
> efi_bgrt_init(), for example. After mm_init(), memblock is
On 01/02/17 at 07:44pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE
> Also, define Elf_Word and use it instead of generic u32 or the more
> specific Elf64_Word.
>
> Signed-off-by:
On 01/02/17 at 07:44pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE
> Also, define Elf_Word and use it instead of generic u32 or the more
> specific Elf64_Word.
>
> Signed-off-by:
Hi, Hari
On 01/02/17 at 07:43pm, Hari Bathini wrote:
> Traditionally, kdump is used to save vmcore in case of a crash. Some
> architectures like powerpc can save vmcore using architecture specific
> support instead of kexec/kdump mechanism. Such architecture specific
> support also needs to
Hi, Hari
On 01/02/17 at 07:43pm, Hari Bathini wrote:
> Traditionally, kdump is used to save vmcore in case of a crash. Some
> architectures like powerpc can save vmcore using architecture specific
> support instead of kexec/kdump mechanism. Such architecture specific
> support also needs to
Vivek, thanks for ccing me..
On 01/03/17 at 04:34pm, Nicholas Mc Guire wrote:
> On Tue, Jan 03, 2017 at 10:38:14AM -0500, Vivek Goyal wrote:
> > On Fri, Dec 23, 2016 at 12:43:07PM +0100, Nicholas Mc Guire wrote:
> > > Add the missing declarations of basic purgatory functions and variables
> > >
Vivek, thanks for ccing me..
On 01/03/17 at 04:34pm, Nicholas Mc Guire wrote:
> On Tue, Jan 03, 2017 at 10:38:14AM -0500, Vivek Goyal wrote:
> > On Fri, Dec 23, 2016 at 12:43:07PM +0100, Nicholas Mc Guire wrote:
> > > Add the missing declarations of basic purgatory functions and variables
> > >
not possible for a newly
> > kexec'd kernel to access the same boot services regions that the
> > initial boot kernel had access to unless they are reserved by every
> > kexec kernel in the chain.
> >
> > Tested-by: Dave Young <dyo...@redhat.com> [kexec/kdump]
>
; kexec'd kernel to access the same boot services regions that the
> > initial boot kernel had access to unless they are reserved by every
> > kexec kernel in the chain.
> >
> > Tested-by: Dave Young [kexec/kdump]
> > Tested-by: Ard Biesheuvel [arm]
> > Acked-by:
Hi,
With recent mainline kernel, I see a BUG, it is easy to reproduce,
just plugging the usb microphone, bisected the first bad commit is:
16200948d8353fe29a473a394d7d26790deae0e7 is the first bad commit
commit 16200948d8353fe29a473a394d7d26790deae0e7
Author: Takashi Iwai
Date:
Hi,
With recent mainline kernel, I see a BUG, it is easy to reproduce,
just plugging the usb microphone, bisected the first bad commit is:
16200948d8353fe29a473a394d7d26790deae0e7 is the first bad commit
commit 16200948d8353fe29a473a394d7d26790deae0e7
Author: Takashi Iwai
Date: Mon Dec 5
601 - 700 of 2643 matches
Mail list logo