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