* [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem @ 2019-12-04 14:52 Ard Biesheuvel 2019-12-04 17:17 ` Masayoshi Mizuma 0 siblings, 1 reply; 6+ messages in thread From: Ard Biesheuvel @ 2019-12-04 14:52 UTC (permalink / raw) To: linux-efi Cc: mark.rutland, Masayoshi Mizuma, kexec, d.hatayama, james.morse, Ard Biesheuvel Memory regions that are reserved using efi_mem_reserve_persistent() are recorded in a special EFI config table which survives kexec, allowing the incoming kernel to honour them as well. However, such reservations are not visible in /proc/iomem, and so the kexec tools that load the incoming kernel and its initrd into memory may overwrite these reserved regions before the incoming kernel has a chance to reserve them from further use. So add these reservations to /proc/iomem as they are created. Note that reservations that are inherited from a previous kernel are memblock_reserve()'d early on, so they are already visible in /proc/iomem. Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Cc: d.hatayama@fujitsu.com Cc: kexec@lists.infradead.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- drivers/firmware/efi/efi.c | 29 ++++++++++++++++++-- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index d101f072c8f8..fcd82dde23c8 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -979,6 +979,24 @@ static int __init efi_memreserve_map_root(void) return 0; } +static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size) +{ + struct resource *res, *parent; + + res = kzalloc(sizeof(struct resource), GFP_ATOMIC); + if (!res) + return -ENOMEM; + + res->name = "reserved"; + res->flags = IORESOURCE_MEM; + res->start = addr; + res->end = addr + size - 1; + + /* we expect a conflict with a 'System RAM' region */ + parent = request_resource_conflict(&iomem_resource, res); + return parent ? request_resource(parent, res) : 0; +} + int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) { struct linux_efi_memreserve *rsv; @@ -1001,9 +1019,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) if (index < rsv->size) { rsv->entry[index].base = addr; rsv->entry[index].size = size; - memunmap(rsv); - return 0; + return efi_mem_reserve_iomem(addr, size); } memunmap(rsv); } @@ -1013,6 +1030,12 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) if (!rsv) return -ENOMEM; + rc = efi_mem_reserve_iomem(__pa(rsv), SZ_4K); + if (rc) { + free_page(rsv); + return rc; + } + /* * The memremap() call above assumes that a linux_efi_memreserve entry * never crosses a page boundary, so let's ensure that this remains true @@ -1029,7 +1052,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) efi_memreserve_root->next = __pa(rsv); spin_unlock(&efi_mem_reserve_persistent_lock); - return 0; + return efi_mem_reserve_iomem(addr, size); } static int __init efi_memreserve_root_init(void) -- 2.17.1 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem 2019-12-04 14:52 [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel @ 2019-12-04 17:17 ` Masayoshi Mizuma 2019-12-04 18:17 ` James Morse 0 siblings, 1 reply; 6+ messages in thread From: Masayoshi Mizuma @ 2019-12-04 17:17 UTC (permalink / raw) To: Ard Biesheuvel Cc: mark.rutland, Masayoshi Mizuma, linux-efi, kexec, james.morse, d.hatayama Hello Ard, Thank you for sending the patch, but unfortunately it doesn't work for the issue... After applied your patch, the LPI tables are marked as reserved in /proc/iomem like as: 80300000-a1fdffff : System RAM 80480000-8134ffff : Kernel code 81350000-817bffff : reserved 817c0000-82acffff : Kernel data 830f0000-830fffff : reserved # Property table 83480000-83480fff : reserved # Pending table 83490000-8349ffff : reserved # Pending table However, kexec tries to allocate memory from System RAM, it doesn't care the reserved in System RAM. Following example, kexec allocates memory 0x82ad0000-0x86640000 to locate the initrd, and LPI tables are also in the memory region, so LPI tables will be destroyed by kexec reboot. # kexec -d -l /boot/vmlinuz-5.4.1+ --initrd=/boot/initramfs-5.4.1+.img ... initrd: base 82ad0000, size 3b67c6fh (62291055) ... segment[1].mem = 0x82ad0000 segment[1].memsz = 0x3b70000 # 0x86640000 (== 0x82ad0000 + 0x3b70000) ... I'm not sure why kexec doesn't care the reserved in System RAM, however, if the kexec behaivor is right, the LPI tables should not belong to System RAM. Like as: 80300000-830effff : System RAM 80480000-8134ffff : Kernel code 81350000-817bffff : reserved 817c0000-82acffff : Kernel data 830f0000-830fffff : reserved # Property table 83480000-83480fff : reserved # Pending table 83490000-8349ffff : reserved # Pending table 834a0000-a1fdffff : System RAM I don't have ideas to separete LPI tables from System RAM... so I tried to add a new file to inform the LPI tables to userspace. Thanks, Masa On Wed, Dec 04, 2019 at 02:52:33PM +0000, Ard Biesheuvel wrote: > Memory regions that are reserved using efi_mem_reserve_persistent() > are recorded in a special EFI config table which survives kexec, > allowing the incoming kernel to honour them as well. However, > such reservations are not visible in /proc/iomem, and so the kexec > tools that load the incoming kernel and its initrd into memory may > overwrite these reserved regions before the incoming kernel has a > chance to reserve them from further use. > > So add these reservations to /proc/iomem as they are created. Note > that reservations that are inherited from a previous kernel are > memblock_reserve()'d early on, so they are already visible in > /proc/iomem. > > Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > Cc: d.hatayama@fujitsu.com > Cc: kexec@lists.infradead.org > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > drivers/firmware/efi/efi.c | 29 ++++++++++++++++++-- > 1 file changed, 26 insertions(+), 3 deletions(-) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index d101f072c8f8..fcd82dde23c8 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -979,6 +979,24 @@ static int __init efi_memreserve_map_root(void) > return 0; > } > > +static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size) > +{ > + struct resource *res, *parent; > + > + res = kzalloc(sizeof(struct resource), GFP_ATOMIC); > + if (!res) > + return -ENOMEM; > + > + res->name = "reserved"; > + res->flags = IORESOURCE_MEM; > + res->start = addr; > + res->end = addr + size - 1; > + > + /* we expect a conflict with a 'System RAM' region */ > + parent = request_resource_conflict(&iomem_resource, res); > + return parent ? request_resource(parent, res) : 0; > +} > + > int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > { > struct linux_efi_memreserve *rsv; > @@ -1001,9 +1019,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > if (index < rsv->size) { > rsv->entry[index].base = addr; > rsv->entry[index].size = size; > - > memunmap(rsv); > - return 0; > + return efi_mem_reserve_iomem(addr, size); > } > memunmap(rsv); > } > @@ -1013,6 +1030,12 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > if (!rsv) > return -ENOMEM; > > + rc = efi_mem_reserve_iomem(__pa(rsv), SZ_4K); > + if (rc) { > + free_page(rsv); > + return rc; > + } > + > /* > * The memremap() call above assumes that a linux_efi_memreserve entry > * never crosses a page boundary, so let's ensure that this remains true > @@ -1029,7 +1052,7 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > efi_memreserve_root->next = __pa(rsv); > spin_unlock(&efi_mem_reserve_persistent_lock); > > - return 0; > + return efi_mem_reserve_iomem(addr, size); > } > > static int __init efi_memreserve_root_init(void) > -- > 2.17.1 > > > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem 2019-12-04 17:17 ` Masayoshi Mizuma @ 2019-12-04 18:17 ` James Morse 2019-12-04 18:57 ` Masayoshi Mizuma 0 siblings, 1 reply; 6+ messages in thread From: James Morse @ 2019-12-04 18:17 UTC (permalink / raw) To: Masayoshi Mizuma, Ard Biesheuvel Cc: mark.rutland, Masayoshi Mizuma, linux-efi, kexec, d.hatayama Hi Masa, On 04/12/2019 17:17, Masayoshi Mizuma wrote: > Thank you for sending the patch, but unfortunately it doesn't work for the issue... > > After applied your patch, the LPI tables are marked as reserved in > /proc/iomem like as: > > 80300000-a1fdffff : System RAM > 80480000-8134ffff : Kernel code > 81350000-817bffff : reserved > 817c0000-82acffff : Kernel data > 830f0000-830fffff : reserved # Property table > 83480000-83480fff : reserved # Pending table > 83490000-8349ffff : reserved # Pending table > > However, kexec tries to allocate memory from System RAM, it doesn't care > the reserved in System RAM. > I'm not sure why kexec doesn't care the reserved in System RAM, however, Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI tables being overwritten by kexec. Which version of kexec-tools are you using? Could you try: https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem > if the kexec behaivor is right, the LPI tables should not belong to > System RAM. > Like as: > > 80300000-830effff : System RAM > 80480000-8134ffff : Kernel code > 81350000-817bffff : reserved > 817c0000-82acffff : Kernel data > 830f0000-830fffff : reserved # Property table > 83480000-83480fff : reserved # Pending table > 83490000-8349ffff : reserved # Pending table > 834a0000-a1fdffff : System RAM > > I don't have ideas to separete LPI tables from System RAM... so I tried > to add a new file to inform the LPI tables to userspace. This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this is kdump can't touch it, as you've told it this isn't memory. As these tables are memory, mapped by the linear map, I think Ard's patch is the right thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make it honour all second level entries. Thanks, James _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem 2019-12-04 18:17 ` James Morse @ 2019-12-04 18:57 ` Masayoshi Mizuma 2019-12-04 20:13 ` Bhupesh SHARMA 0 siblings, 1 reply; 6+ messages in thread From: Masayoshi Mizuma @ 2019-12-04 18:57 UTC (permalink / raw) To: James Morse Cc: mark.rutland, Masayoshi Mizuma, linux-efi, kexec, d.hatayama, Ard Biesheuvel On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote: > Hi Masa, > > On 04/12/2019 17:17, Masayoshi Mizuma wrote: > > Thank you for sending the patch, but unfortunately it doesn't work for the issue... > > > > After applied your patch, the LPI tables are marked as reserved in > > /proc/iomem like as: > > > > 80300000-a1fdffff : System RAM > > 80480000-8134ffff : Kernel code > > 81350000-817bffff : reserved > > 817c0000-82acffff : Kernel data > > 830f0000-830fffff : reserved # Property table > > 83480000-83480fff : reserved # Pending table > > 83490000-8349ffff : reserved # Pending table > > > > However, kexec tries to allocate memory from System RAM, it doesn't care > > the reserved in System RAM. > > > I'm not sure why kexec doesn't care the reserved in System RAM, however, > > Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI > tables being overwritten by kexec. > > Which version of kexec-tools are you using? Could you try: > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem Thanks a lot! It worked and the issue is gone with Ard's patch and the linaro kexec (arm64/resv_mem branch). Ard, please feel free to add: Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > > > if the kexec behaivor is right, the LPI tables should not belong to > > System RAM. > > > Like as: > > > > 80300000-830effff : System RAM > > 80480000-8134ffff : Kernel code > > 81350000-817bffff : reserved > > 817c0000-82acffff : Kernel data > > 830f0000-830fffff : reserved # Property table > > 83480000-83480fff : reserved # Pending table > > 83490000-8349ffff : reserved # Pending table > > 834a0000-a1fdffff : System RAM > > > > I don't have ideas to separete LPI tables from System RAM... so I tried > > to add a new file to inform the LPI tables to userspace. > > This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this > is kdump can't touch it, as you've told it this isn't memory. > > As these tables are memory, mapped by the linear map, I think Ard's patch is the right > thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make > it honour all second level entries. I used the kexec on the top of master branch: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Should we use the linaro kexec for aarch64 machine? Or will the arm64/resv_mem branch be merged to the kexec on git.kernel.org...? Thanks! Masa _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem 2019-12-04 18:57 ` Masayoshi Mizuma @ 2019-12-04 20:13 ` Bhupesh SHARMA 2019-12-05 9:28 ` Ard Biesheuvel 0 siblings, 1 reply; 6+ messages in thread From: Bhupesh SHARMA @ 2019-12-04 20:13 UTC (permalink / raw) To: Masayoshi Mizuma Cc: Mark Rutland, Masayoshi Mizuma, linux-efi, Bhupesh Sharma, kexec, Ard Biesheuvel, Simon Horman, James Morse, d.hatayama Hello Masa, (+Cc Simon) On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma <msys.mizuma@gmail.com> wrote: > > On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote: > > Hi Masa, > > > > On 04/12/2019 17:17, Masayoshi Mizuma wrote: > > > Thank you for sending the patch, but unfortunately it doesn't work for the issue... > > > > > > After applied your patch, the LPI tables are marked as reserved in > > > /proc/iomem like as: > > > > > > 80300000-a1fdffff : System RAM > > > 80480000-8134ffff : Kernel code > > > 81350000-817bffff : reserved > > > 817c0000-82acffff : Kernel data > > > 830f0000-830fffff : reserved # Property table > > > 83480000-83480fff : reserved # Pending table > > > 83490000-8349ffff : reserved # Pending table > > > > > > However, kexec tries to allocate memory from System RAM, it doesn't care > > > the reserved in System RAM. > > > > > I'm not sure why kexec doesn't care the reserved in System RAM, however, > > > > Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI > > tables being overwritten by kexec. > > > > Which version of kexec-tools are you using? Could you try: > > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem > > Thanks a lot! It worked and the issue is gone with Ard's patch and > the linaro kexec (arm64/resv_mem branch). > > Ard, please feel free to add: > > Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Same results at my side, so: Tested-and-Reviewed-by: Bhipesh Sharma <bhsharma@redhat.com> > > > > > if the kexec behaivor is right, the LPI tables should not belong to > > > System RAM. > > > > > Like as: > > > > > > 80300000-830effff : System RAM > > > 80480000-8134ffff : Kernel code > > > 81350000-817bffff : reserved > > > 817c0000-82acffff : Kernel data > > > 830f0000-830fffff : reserved # Property table > > > 83480000-83480fff : reserved # Pending table > > > 83490000-8349ffff : reserved # Pending table > > > 834a0000-a1fdffff : System RAM > > > > > > I don't have ideas to separete LPI tables from System RAM... so I tried > > > to add a new file to inform the LPI tables to userspace. > > > > This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this > > is kdump can't touch it, as you've told it this isn't memory. > > > > As these tables are memory, mapped by the linear map, I think Ard's patch is the right > > thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make > > it honour all second level entries. > > I used the kexec on the top of master branch: > git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git > > Should we use the linaro kexec for aarch64 machine? > Or will the arm64/resv_mem branch be merged to the kexec on > git.kernel.org...? Glad that Ard's patch fixes the issue for you. Regarding Akashi's patch, I think it was sent to upstream kexec-tools some time ago (see [0}) but seems not integrated in upstream kexec-tools (now I noticed my Tested-by email for the same got bounced off due to some gmail msmtp setting issues at my end - sorry for that). I have added Simon in Cc list. Hi Simon, Can you please help pick [0] in upstream kexec-tools with Tested-by from Masa and myself? Thanks a lot for your help. [0]. http://lists.infradead.org/pipermail/kexec/2019-January/022201.html Thanks, Bhupesh _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem 2019-12-04 20:13 ` Bhupesh SHARMA @ 2019-12-05 9:28 ` Ard Biesheuvel 0 siblings, 0 replies; 6+ messages in thread From: Ard Biesheuvel @ 2019-12-05 9:28 UTC (permalink / raw) To: Bhupesh SHARMA Cc: Mark Rutland, Masayoshi Mizuma, linux-efi, Bhupesh Sharma, Kexec Mailing List, Ard Biesheuvel, Simon Horman, James Morse, Masayoshi Mizuma, d.hatayama On Wed, 4 Dec 2019 at 20:13, Bhupesh SHARMA <bhupesh.linux@gmail.com> wrote: > > Hello Masa, > > (+Cc Simon) > > On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma <msys.mizuma@gmail.com> wrote: > > > > On Wed, Dec 04, 2019 at 06:17:59PM +0000, James Morse wrote: > > > Hi Masa, > > > > > > On 04/12/2019 17:17, Masayoshi Mizuma wrote: > > > > Thank you for sending the patch, but unfortunately it doesn't work for the issue... > > > > > > > > After applied your patch, the LPI tables are marked as reserved in > > > > /proc/iomem like as: > > > > > > > > 80300000-a1fdffff : System RAM > > > > 80480000-8134ffff : Kernel code > > > > 81350000-817bffff : reserved > > > > 817c0000-82acffff : Kernel data > > > > 830f0000-830fffff : reserved # Property table > > > > 83480000-83480fff : reserved # Pending table > > > > 83490000-8349ffff : reserved # Pending table > > > > > > > > However, kexec tries to allocate memory from System RAM, it doesn't care > > > > the reserved in System RAM. > > > > > > > I'm not sure why kexec doesn't care the reserved in System RAM, however, > > > > > > Hmm, we added these to fix a problem with the UEFI memory map, and more recently ACPI > > > tables being overwritten by kexec. > > > > > > Which version of kexec-tools are you using? Could you try: > > > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git/commit/?h=arm64/resv_mem > > > > Thanks a lot! It worked and the issue is gone with Ard's patch and > > the linaro kexec (arm64/resv_mem branch). > > > > Ard, please feel free to add: > > > > Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > Same results at my side, so: > Tested-and-Reviewed-by: Bhipesh Sharma <bhsharma@redhat.com> > Thank you all. I'll get this queued as a fix with cc:stable for v5.4 > > > > > > > if the kexec behaivor is right, the LPI tables should not belong to > > > > System RAM. > > > > > > > Like as: > > > > > > > > 80300000-830effff : System RAM > > > > 80480000-8134ffff : Kernel code > > > > 81350000-817bffff : reserved > > > > 817c0000-82acffff : Kernel data > > > > 830f0000-830fffff : reserved # Property table > > > > 83480000-83480fff : reserved # Pending table > > > > 83490000-8349ffff : reserved # Pending table > > > > 834a0000-a1fdffff : System RAM > > > > > > > > I don't have ideas to separete LPI tables from System RAM... so I tried > > > > to add a new file to inform the LPI tables to userspace. > > > > > > This is how 'nomap' memory appears, we carve it out of System RAM. A side effect of this > > > is kdump can't touch it, as you've told it this isn't memory. > > > > > > As these tables are memory, mapped by the linear map, I think Ard's patch is the right > > > thing to do ... I suspect your kexec-tools doesn't have those patches from Akashi to make > > > it honour all second level entries. > > > > I used the kexec on the top of master branch: > > git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git > > > > Should we use the linaro kexec for aarch64 machine? > > Or will the arm64/resv_mem branch be merged to the kexec on > > git.kernel.org...? > > Glad that Ard's patch fixes the issue for you. > Regarding Akashi's patch, I think it was sent to upstream kexec-tools > some time ago (see [0}) but seems not integrated in upstream > kexec-tools (now I noticed my Tested-by email for the same got bounced > off due to some gmail msmtp setting issues at my end - sorry for > that). I have added Simon in Cc list. > > Hi Simon, > > Can you please help pick [0] in upstream kexec-tools with Tested-by > from Masa and myself? Thanks a lot for your help. > > [0]. http://lists.infradead.org/pipermail/kexec/2019-January/022201.html > > Thanks, > Bhupesh _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-05 9:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-12-04 14:52 [PATCH] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel 2019-12-04 17:17 ` Masayoshi Mizuma 2019-12-04 18:17 ` James Morse 2019-12-04 18:57 ` Masayoshi Mizuma 2019-12-04 20:13 ` Bhupesh SHARMA 2019-12-05 9:28 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox