| Message ID | 20180921163246.16632-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | efi: add support for persistent memory reservations | expand |
On 9/21/2018 10:32 AM, Ard Biesheuvel wrote: > Add support for persistent memory reservations across kexec reboot on EFI > systems by introducing a Linux-specific UEFI configuration table that points > to a linked list in memory that can be augmented by each successive kexec > kernel to describe regions in memory that the subsequent kernel should treat > as reserved. > > The specific use case for this feature is GICv3 ARM systems that are not > able to disable DMA access to LPI tables, meaning we have to reserve them > and make the next kernel reuse the existing tables rather than allocating > them from scratch. As far as I recall, Shanker Donthineni attempted to address a similar (the same?) issue. I think we would be very interested, if that is the case. Is there another series that depends on these changes? If not, can you describe the plan for this? -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
On Fri, 21 Sep 2018 at 10:14, Jeffrey Hugo <jhugo@codeaurora.org> wrote: > > On 9/21/2018 10:32 AM, Ard Biesheuvel wrote: > > Add support for persistent memory reservations across kexec reboot on EFI > > systems by introducing a Linux-specific UEFI configuration table that points > > to a linked list in memory that can be augmented by each successive kexec > > kernel to describe regions in memory that the subsequent kernel should treat > > as reserved. > > > > The specific use case for this feature is GICv3 ARM systems that are not > > able to disable DMA access to LPI tables, meaning we have to reserve them > > and make the next kernel reuse the existing tables rather than allocating > > them from scratch. > > As far as I recall, Shanker Donthineni attempted to address a similar > (the same?) issue. I think we would be very interested, if that is the > case. > > Is there another series that depends on these changes? If not, can you > describe the plan for this? > Marc Zyngier should have some patches out shortly for this.
On Fri, 21 Sep 2018 18:14:43 +0100, Jeffrey Hugo <jhugo@codeaurora.org> wrote: > > On 9/21/2018 10:32 AM, Ard Biesheuvel wrote: > > Add support for persistent memory reservations across kexec reboot on EFI > > systems by introducing a Linux-specific UEFI configuration table that points > > to a linked list in memory that can be augmented by each successive kexec > > kernel to describe regions in memory that the subsequent kernel should treat > > as reserved. > > > > The specific use case for this feature is GICv3 ARM systems that are not > > able to disable DMA access to LPI tables, meaning we have to reserve them > > and make the next kernel reuse the existing tables rather than allocating > > them from scratch. > > As far as I recall, Shanker Donthineni attempted to address a similar > (the same?) issue. I think we would be very interested, if that is > the case. Shanker's patches didn't solve the story of preserving the allocated memory across kexec, and were just expecting to get similar mappings. Ard's patches allow us to track the allocation, and to reuse those if it is safe to do so. > Is there another series that depends on these changes? If not, can > you describe the plan for this? I have a series which does exactly that[1], and that rely on Ard's patches. I'm about to post these patches now the dependency is public. Thanks, M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gicv3-kdump -- Jazz is not dead, it just smell funny.
On 21 September 2018 at 10:46, Marc Zyngier <marc.zyngier@arm.com> wrote: > On Fri, 21 Sep 2018 18:14:43 +0100, > Jeffrey Hugo <jhugo@codeaurora.org> wrote: >> >> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote: >> > Add support for persistent memory reservations across kexec reboot on EFI >> > systems by introducing a Linux-specific UEFI configuration table that points >> > to a linked list in memory that can be augmented by each successive kexec >> > kernel to describe regions in memory that the subsequent kernel should treat >> > as reserved. >> > >> > The specific use case for this feature is GICv3 ARM systems that are not >> > able to disable DMA access to LPI tables, meaning we have to reserve them >> > and make the next kernel reuse the existing tables rather than allocating >> > them from scratch. >> >> As far as I recall, Shanker Donthineni attempted to address a similar >> (the same?) issue. I think we would be very interested, if that is >> the case. > > Shanker's patches didn't solve the story of preserving the allocated > memory across kexec, and were just expecting to get similar mappings. > > Ard's patches allow us to track the allocation, and to reuse those if > it is safe to do so. > >> Is there another series that depends on these changes? If not, can >> you describe the plan for this? > > I have a series which does exactly that[1], and that rely on Ard's > patches. I'm about to post these patches now the dependency is public. > FYI the efi_reserve_mem_region() function has been renamed to efi_mem_reserve_persistent()
On Fri, 21 Sep 2018 18:51:08 +0100, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On 21 September 2018 at 10:46, Marc Zyngier <marc.zyngier@arm.com> wrote: > > On Fri, 21 Sep 2018 18:14:43 +0100, > > Jeffrey Hugo <jhugo@codeaurora.org> wrote: > >> > >> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote: > >> > Add support for persistent memory reservations across kexec reboot on EFI > >> > systems by introducing a Linux-specific UEFI configuration table that points > >> > to a linked list in memory that can be augmented by each successive kexec > >> > kernel to describe regions in memory that the subsequent kernel should treat > >> > as reserved. > >> > > >> > The specific use case for this feature is GICv3 ARM systems that are not > >> > able to disable DMA access to LPI tables, meaning we have to reserve them > >> > and make the next kernel reuse the existing tables rather than allocating > >> > them from scratch. > >> > >> As far as I recall, Shanker Donthineni attempted to address a similar > >> (the same?) issue. I think we would be very interested, if that is > >> the case. > > > > Shanker's patches didn't solve the story of preserving the allocated > > memory across kexec, and were just expecting to get similar mappings. > > > > Ard's patches allow us to track the allocation, and to reuse those if > > it is safe to do so. > > > >> Is there another series that depends on these changes? If not, can > >> you describe the plan for this? > > > > I have a series which does exactly that[1], and that rely on Ard's > > patches. I'm about to post these patches now the dependency is public. > > > > FYI the efi_reserve_mem_region() function has been renamed to > efi_mem_reserve_persistent() Ah, indeed. Now fixed. Thanks, M. -- Jazz is not dead, it just smell funny.
Hi, On 09/21/2018 11:32 AM, Ard Biesheuvel wrote: > Add support for persistent memory reservations across kexec reboot on EFI > systems by introducing a Linux-specific UEFI configuration table that points > to a linked list in memory that can be augmented by each successive kexec > kernel to describe regions in memory that the subsequent kernel should treat > as reserved. > > The specific use case for this feature is GICv3 ARM systems that are not > able to disable DMA access to LPI tables, meaning we have to reserve them > and make the next kernel reuse the existing tables rather than allocating > them from scratch. When combined with Marc's patch set this fixes kdump on a QC system. Tested-by: Jeremy Linton <jeremy.linton@arm.com> Thanks, > > Cc: Jeremy Linton <jeremy.linton@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> > > Ard Biesheuvel (3): > efi: honour memory reservations passed via a linux specific config > table > efi/arm: libstub: add a root memreserve config table > efi: add API to reserve memory persistently across kexec reboot > > drivers/firmware/efi/efi.c | 59 +++++++++++++++++++- > drivers/firmware/efi/libstub/arm-stub.c | 27 +++++++++ > include/linux/efi.h | 9 +++ > 3 files changed, 94 insertions(+), 1 deletion(-) >
Add support for persistent memory reservations across kexec reboot on EFI systems by introducing a Linux-specific UEFI configuration table that points to a linked list in memory that can be augmented by each successive kexec kernel to describe regions in memory that the subsequent kernel should treat as reserved. The specific use case for this feature is GICv3 ARM systems that are not able to disable DMA access to LPI tables, meaning we have to reserve them and make the next kernel reuse the existing tables rather than allocating them from scratch. Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Ard Biesheuvel (3): efi: honour memory reservations passed via a linux specific config table efi/arm: libstub: add a root memreserve config table efi: add API to reserve memory persistently across kexec reboot drivers/firmware/efi/efi.c | 59 +++++++++++++++++++- drivers/firmware/efi/libstub/arm-stub.c | 27 +++++++++ include/linux/efi.h | 9 +++ 3 files changed, 94 insertions(+), 1 deletion(-) -- 2.17.1