Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

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

Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted

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

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

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). > >

Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted

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). > >

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

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,

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

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,

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

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

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

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

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

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

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

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

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

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

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

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

Re: [PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

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

Re: [PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

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

[tip:efi/core] efi/x86: Add debug code to print cooked memmap

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

[tip:efi/core] efi/x86: Add debug code to print cooked memmap

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

[tip:efi/core] efi/x86: Move the EFI BGRT init code to early init 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

[tip:efi/core] efi/x86: Move the EFI BGRT init code to early init code

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

Re: [PATCH V3 1/4] efi/x86: move efi bgrt init code to early init code

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 <

Re: [PATCH V3 1/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

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

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

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

Re: [PATCH v2] x86/crash: Update the stale comment in reserve_crashkernel()

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 > --- >

Re: [PATCH v2] x86/crash: Update the stale comment in reserve_crashkernel()

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

[PATCH V3 1/4] efi/x86: move efi bgrt init code to early init code

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

[PATCH V3 1/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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.

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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, > >

Re: [PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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: > >> > > >

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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: > >> > > >

[PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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> ---

[PATCH V2 4/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

[PATCH V2 3/4] efi/x86: add debug code to print cooked memmap

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,

[PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

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:

[PATCH V2 3/4] efi/x86: add debug code to print cooked memmap

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

[PATCH V2 0/4] efi/x86: move efi bgrt init code to early init

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:

[PATCH V2 2/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

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

[PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

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

[PATCH V2 2/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

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

[PATCH V2 1/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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: >

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 3/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

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 +

Re: [PATCH 3/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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;

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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;

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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: > >

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

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 | | | | | | | |

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

[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 =

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

[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 =

[PATCH 0/4] efi/x86: move efi bgrt init code to early init

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 +--

[PATCH 0/4] efi/x86: move efi bgrt init code to early init

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 +--

[PATCH 4/4] efi/x86: add debug code to print cooked memmap

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 +++

[PATCH 3/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.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

[PATCH 4/4] efi/x86: add debug code to print cooked memmap

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

[PATCH 3/4] efi/x86: move efi_print_memmap to drivers/firmware/efi/memmap.c

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

[PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

[PATCH 2/4] efi/x86: move efi bgrt init code to early init code

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

[PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

. 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

[PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

. 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

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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. >

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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. >

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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. &

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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. &

Re: [PATCH V3] purgatory: fix up declarations

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

Re: [PATCH V3] purgatory: fix up declarations

; 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 >

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

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

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

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

Re: [PATCH v4 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

| 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

Re: [PATCH v4 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

> 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

Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

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 > > >>

Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

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

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

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

Re: [PATCH v3 2/5] ia64: reuse append_elf_note() and final_note() functions

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:

Re: [PATCH v3 2/5] ia64: reuse append_elf_note() and final_note() functions

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:

Re: [PATCH v3 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

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

Re: [PATCH v3 1/5] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE

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

Re: [PATCH RFC V2] purgatory: fix up declarations

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 > > >

Re: [PATCH RFC V2] purgatory: fix up declarations

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 > > >

Re: [PATCH 08/29] efi: Allow drivers to reserve boot services forever

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] >

Re: [PATCH 08/29] efi: Allow drivers to reserve boot services forever

; 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:

[snd-usb-audio] BUG: NULL pointer dereference at 0000000000000070

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:

[snd-usb-audio] BUG: NULL pointer dereference at 0000000000000070

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

<    2   3   4   5   6   7   8   9   10   11   >