| Message ID | 20160809015747.28591-1-takahiro.akashi@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > From: James Morse <james.morse@arm.com> > > Add documentation for > linux,crashkernel-base and crashkernel-size, > linux,usable-memory-range, and > linux,elfcorehdr > used by arm64 kexec/kdump to decribe the kdump reserved area, and > the elfcorehdr's location within it. > > Signed-off-by: James Morse <james.morse@arm.com> > [takahiro.akashi@linaro.org: > renamed "usable-memory" to "usable-memory-range", > added "linux,crashkernel-base" and "-size" ] > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > --- > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt > index 6ae9d82..236188a 100644 > --- a/Documentation/devicetree/bindings/chosen.txt > +++ b/Documentation/devicetree/bindings/chosen.txt > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on > book3e) by some versions of kexec-tools to tell the new kernel that it > is being booted by kexec, as the booting environment may differ (e.g. > a different secondary CPU release mechanism) > + > +linux,crashkernel-base > +linux,crashkernel-size > +---------------------- > +These properties (currently used on PowerPC and arm64) indicates > +the base address and the size, respectively, of the reserved memory > +range for crash dump kernel. > +e.g. > + > +/ { > + chosen { > + linux,crashkernel-base = <0x9 0xf0000000>; > + linux,crashkernel-size = <0x0 0x10000000>; > + }; > +}; > + > +linux,usable-memory-range > +------------------------- > + > +This property (currently used only on arm64) holds the memory range, > +the base address and the size, which can be used as system ram on > +the *current* kernel. Note that, if this property is present, any memory > +regions under "memory" nodes in DT blob or ones marked as "conventional > +memory" in EFI memory map should be ignored. > +e.g. > + > +/ { > + chosen { > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > + }; > +}; I've read the discussion on this. I think you should use the existing linux,usable-memory property in the memory nodes. If UEFI systems don't have memory nodes, then you can find an UEFI way to describe this. DT is not the dumping ground for what doesn't fit in UEFI. How do x86 systems work? Rob
Rob, [Cc: Mark] On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: > On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > > From: James Morse <james.morse@arm.com> > > > > Add documentation for > > linux,crashkernel-base and crashkernel-size, > > linux,usable-memory-range, and > > linux,elfcorehdr > > used by arm64 kexec/kdump to decribe the kdump reserved area, and > > the elfcorehdr's location within it. > > > > Signed-off-by: James Morse <james.morse@arm.com> > > [takahiro.akashi@linaro.org: > > renamed "usable-memory" to "usable-memory-range", > > added "linux,crashkernel-base" and "-size" ] > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > --- > > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ > > 1 file changed, 50 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt > > index 6ae9d82..236188a 100644 > > --- a/Documentation/devicetree/bindings/chosen.txt > > +++ b/Documentation/devicetree/bindings/chosen.txt > > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on > > book3e) by some versions of kexec-tools to tell the new kernel that it > > is being booted by kexec, as the booting environment may differ (e.g. > > a different secondary CPU release mechanism) > > + > > +linux,crashkernel-base > > +linux,crashkernel-size > > +---------------------- > > +These properties (currently used on PowerPC and arm64) indicates > > +the base address and the size, respectively, of the reserved memory > > +range for crash dump kernel. > > +e.g. > > + > > +/ { > > + chosen { > > + linux,crashkernel-base = <0x9 0xf0000000>; > > + linux,crashkernel-size = <0x0 0x10000000>; > > + }; > > +}; > > + > > +linux,usable-memory-range > > +------------------------- > > + > > +This property (currently used only on arm64) holds the memory range, > > +the base address and the size, which can be used as system ram on > > +the *current* kernel. Note that, if this property is present, any memory > > +regions under "memory" nodes in DT blob or ones marked as "conventional > > +memory" in EFI memory map should be ignored. > > +e.g. > > + > > +/ { > > + chosen { > > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > > + }; > > +}; > > I've read the discussion on this. I think you should use the existing > linux,usable-memory property in the memory nodes. If UEFI systems don't > have memory nodes, then you can find an UEFI way to describe this. DT is > not the dumping ground for what doesn't fit in UEFI. How do x86 systems > work? Kdump for x86 passes the range of usable memory to crash dump kernel either via: (a) "memmap=nn@ss" command line parameter, or (b) faked BIOS e820 map (a sort of memory map table) (a) was rejected by Mark [1], and (b) is x86-specific. I believe that my approach is better because it works in the same way either on UEFI systems or DT-based systems. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/400122.html Thanks, -Takahiro AKASHI > Rob
On Sun, Aug 21, 2016 at 11:28 PM, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote: > Rob, > [Cc: Mark] > > On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: >> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: >> > From: James Morse <james.morse@arm.com> >> > >> > Add documentation for >> > linux,crashkernel-base and crashkernel-size, >> > linux,usable-memory-range, and >> > linux,elfcorehdr >> > used by arm64 kexec/kdump to decribe the kdump reserved area, and >> > the elfcorehdr's location within it. >> > >> > Signed-off-by: James Morse <james.morse@arm.com> >> > [takahiro.akashi@linaro.org: >> > renamed "usable-memory" to "usable-memory-range", >> > added "linux,crashkernel-base" and "-size" ] >> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> >> > --- >> > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ >> > 1 file changed, 50 insertions(+) >> > >> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt >> > index 6ae9d82..236188a 100644 >> > --- a/Documentation/devicetree/bindings/chosen.txt >> > +++ b/Documentation/devicetree/bindings/chosen.txt >> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on >> > book3e) by some versions of kexec-tools to tell the new kernel that it >> > is being booted by kexec, as the booting environment may differ (e.g. >> > a different secondary CPU release mechanism) >> > + >> > +linux,crashkernel-base >> > +linux,crashkernel-size >> > +---------------------- >> > +These properties (currently used on PowerPC and arm64) indicates >> > +the base address and the size, respectively, of the reserved memory >> > +range for crash dump kernel. >> > +e.g. >> > + >> > +/ { >> > + chosen { >> > + linux,crashkernel-base = <0x9 0xf0000000>; >> > + linux,crashkernel-size = <0x0 0x10000000>; >> > + }; >> > +}; >> > + >> > +linux,usable-memory-range >> > +------------------------- >> > + >> > +This property (currently used only on arm64) holds the memory range, >> > +the base address and the size, which can be used as system ram on >> > +the *current* kernel. Note that, if this property is present, any memory >> > +regions under "memory" nodes in DT blob or ones marked as "conventional >> > +memory" in EFI memory map should be ignored. >> > +e.g. >> > + >> > +/ { >> > + chosen { >> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; >> > + }; >> > +}; >> >> I've read the discussion on this. I think you should use the existing >> linux,usable-memory property in the memory nodes. If UEFI systems don't >> have memory nodes, then you can find an UEFI way to describe this. DT is >> not the dumping ground for what doesn't fit in UEFI. How do x86 systems >> work? > > Kdump for x86 passes the range of usable memory to crash dump kernel > either via: > (a) "memmap=nn@ss" command line parameter, or > (b) faked BIOS e820 map (a sort of memory map table) > > (a) was rejected by Mark [1], and (b) is x86-specific. > > I believe that my approach is better because it works in the same way > either on UEFI systems or DT-based systems. So we have a new way for both UEFI and DT. If UEFI folks can't come up with a standard way to do things in the UEFI standard, then we just dump them into DT? I'd rather see alignment with existing DT systems (PPC) and in particular the tools. Rob
Rob, On Tue, Aug 30, 2016 at 11:34:10AM -0500, Rob Herring wrote: > On Sun, Aug 21, 2016 at 11:28 PM, AKASHI Takahiro > <takahiro.akashi@linaro.org> wrote: > > Rob, > > [Cc: Mark] > > > > On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: > >> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > >> > From: James Morse <james.morse@arm.com> > >> > > >> > Add documentation for > >> > linux,crashkernel-base and crashkernel-size, > >> > linux,usable-memory-range, and > >> > linux,elfcorehdr > >> > used by arm64 kexec/kdump to decribe the kdump reserved area, and > >> > the elfcorehdr's location within it. > >> > > >> > Signed-off-by: James Morse <james.morse@arm.com> > >> > [takahiro.akashi@linaro.org: > >> > renamed "usable-memory" to "usable-memory-range", > >> > added "linux,crashkernel-base" and "-size" ] > >> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > >> > --- > >> > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ > >> > 1 file changed, 50 insertions(+) > >> > > >> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt > >> > index 6ae9d82..236188a 100644 > >> > --- a/Documentation/devicetree/bindings/chosen.txt > >> > +++ b/Documentation/devicetree/bindings/chosen.txt > >> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on > >> > book3e) by some versions of kexec-tools to tell the new kernel that it > >> > is being booted by kexec, as the booting environment may differ (e.g. > >> > a different secondary CPU release mechanism) > >> > + > >> > +linux,crashkernel-base > >> > +linux,crashkernel-size > >> > +---------------------- > >> > +These properties (currently used on PowerPC and arm64) indicates > >> > +the base address and the size, respectively, of the reserved memory > >> > +range for crash dump kernel. > >> > +e.g. > >> > + > >> > +/ { > >> > + chosen { > >> > + linux,crashkernel-base = <0x9 0xf0000000>; > >> > + linux,crashkernel-size = <0x0 0x10000000>; > >> > + }; > >> > +}; > >> > + > >> > +linux,usable-memory-range > >> > +------------------------- > >> > + > >> > +This property (currently used only on arm64) holds the memory range, > >> > +the base address and the size, which can be used as system ram on > >> > +the *current* kernel. Note that, if this property is present, any memory > >> > +regions under "memory" nodes in DT blob or ones marked as "conventional > >> > +memory" in EFI memory map should be ignored. > >> > +e.g. > >> > + > >> > +/ { > >> > + chosen { > >> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > >> > + }; > >> > +}; > >> > >> I've read the discussion on this. I think you should use the existing > >> linux,usable-memory property in the memory nodes. If UEFI systems don't > >> have memory nodes, then you can find an UEFI way to describe this. DT is > >> not the dumping ground for what doesn't fit in UEFI. How do x86 systems > >> work? > > > > Kdump for x86 passes the range of usable memory to crash dump kernel > > either via: > > (a) "memmap=nn@ss" command line parameter, or > > (b) faked BIOS e820 map (a sort of memory map table) > > > > (a) was rejected by Mark [1], and (b) is x86-specific. > > > > I believe that my approach is better because it works in the same way > > either on UEFI systems or DT-based systems. > > So we have a new way for both UEFI and DT. If UEFI folks can't come up > with a standard way to do things in the UEFI standard, then we just > dump them into DT? No, I don't think so. According to "Documentation/devicetree/bindings/chosen.txt, "The chosen node does not represent a real device, but serves as a place for passing data between firmware and the operating system, like boot arguments." Since kexec/dump is some sort of boot loader, it all makes sense to add a new property as an interface from the old kernel(kexec/dump) to the new kernel. So my approach doesn't break any DT rules. Please note that, even on UEFI/APCI systems, there are already a few properties used under /chosen, like "linux,uefi-system-table" and "linux,mmap-*." (Those properties are currently *not* defined in this document, though.) > I'd rather see alignment with existing DT systems > (PPC) and in particular the tools. I'm not sure what you mean here, but I guess: 1) On DT-only systems, we should follow the way that PPC does. (That is, adding "usable-memory" property to each "memory" node.) 2) On UEFI/ACPI system, we must invent a new own way for our purpose because, as I said before, there is no standard, but x86-specific way. Is this what you want to do? If so, do you agree to my approach of adding "linux,usable-memory-range" property to /chosen *for UEFI/ACPI use*? Thanks, -Takahiro AKASHI > Rob
On Wed, Aug 31, 2016 at 08:45:46AM +0900, AKASHI Takahiro wrote: > Rob, > > On Tue, Aug 30, 2016 at 11:34:10AM -0500, Rob Herring wrote: > > On Sun, Aug 21, 2016 at 11:28 PM, AKASHI Takahiro > > <takahiro.akashi@linaro.org> wrote: > > > Rob, > > > [Cc: Mark] > > > > > > On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: > > >> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > > >> > From: James Morse <james.morse@arm.com> > > >> > > > >> > Add documentation for > > >> > linux,crashkernel-base and crashkernel-size, > > >> > linux,usable-memory-range, and > > >> > linux,elfcorehdr > > >> > used by arm64 kexec/kdump to decribe the kdump reserved area, and > > >> > the elfcorehdr's location within it. > > >> > > > >> > Signed-off-by: James Morse <james.morse@arm.com> > > >> > [takahiro.akashi@linaro.org: > > >> > renamed "usable-memory" to "usable-memory-range", > > >> > added "linux,crashkernel-base" and "-size" ] > > >> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > >> > --- > > >> > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ > > >> > 1 file changed, 50 insertions(+) > > >> > > > >> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt > > >> > index 6ae9d82..236188a 100644 > > >> > --- a/Documentation/devicetree/bindings/chosen.txt > > >> > +++ b/Documentation/devicetree/bindings/chosen.txt > > >> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on > > >> > book3e) by some versions of kexec-tools to tell the new kernel that it > > >> > is being booted by kexec, as the booting environment may differ (e.g. > > >> > a different secondary CPU release mechanism) > > >> > + > > >> > +linux,crashkernel-base > > >> > +linux,crashkernel-size > > >> > +---------------------- > > >> > +These properties (currently used on PowerPC and arm64) indicates > > >> > +the base address and the size, respectively, of the reserved memory > > >> > +range for crash dump kernel. > > >> > +e.g. > > >> > + > > >> > +/ { > > >> > + chosen { > > >> > + linux,crashkernel-base = <0x9 0xf0000000>; > > >> > + linux,crashkernel-size = <0x0 0x10000000>; > > >> > + }; > > >> > +}; > > >> > + > > >> > +linux,usable-memory-range > > >> > +------------------------- > > >> > + > > >> > +This property (currently used only on arm64) holds the memory range, > > >> > +the base address and the size, which can be used as system ram on > > >> > +the *current* kernel. Note that, if this property is present, any memory > > >> > +regions under "memory" nodes in DT blob or ones marked as "conventional > > >> > +memory" in EFI memory map should be ignored. > > >> > +e.g. > > >> > + > > >> > +/ { > > >> > + chosen { > > >> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > > >> > + }; > > >> > +}; > > >> > > >> I've read the discussion on this. I think you should use the existing > > >> linux,usable-memory property in the memory nodes. If UEFI systems don't > > >> have memory nodes, then you can find an UEFI way to describe this. DT is > > >> not the dumping ground for what doesn't fit in UEFI. How do x86 systems > > >> work? > > > > > > Kdump for x86 passes the range of usable memory to crash dump kernel > > > either via: > > > (a) "memmap=nn@ss" command line parameter, or > > > (b) faked BIOS e820 map (a sort of memory map table) > > > > > > (a) was rejected by Mark [1], and (b) is x86-specific. > > > > > > I believe that my approach is better because it works in the same way > > > either on UEFI systems or DT-based systems. > > > > So we have a new way for both UEFI and DT. If UEFI folks can't come up > > with a standard way to do things in the UEFI standard, then we just > > dump them into DT? > > No, I don't think so. > According to "Documentation/devicetree/bindings/chosen.txt, > "The chosen node does not represent a real device, but serves as a place > for passing data between firmware and the operating system, like boot > arguments." > > Since kexec/dump is some sort of boot loader, it all makes sense to > add a new property as an interface from the old kernel(kexec/dump) > to the new kernel. So my approach doesn't break any DT rules. > > Please note that, even on UEFI/APCI systems, there are already a few > properties used under /chosen, like "linux,uefi-system-table" and > "linux,mmap-*." > (Those properties are currently *not* defined in this document, though.) > > > I'd rather see alignment with existing DT systems > > (PPC) and in particular the tools. > > I'm not sure what you mean here, but I guess: > 1) On DT-only systems, we should follow the way that PPC does. > (That is, adding "usable-memory" property to each "memory" node.) > 2) On UEFI/ACPI system, we must invent a new own way for our purpose > because, as I said before, there is no standard, but x86-specific way. > > Is this what you want to do? > > If so, > do you agree to my approach of adding "linux,usable-memory-range" property > to /chosen *for UEFI/ACPI use*? I've got another idea here: using "/memreserve/" field. All the memory regions used by the crashed kernel would be added as "/memreserve/" and be memblock_reserve'd later in crash dump kernel. Consequently, they will be excluded from the usable memory. Obviously, - this approach will work both on UEFI/ACPI and DT-only systems, and - patch#2 ("memblock: add memblock_cap_memory_range()"), as well as "linux,usable-memory-range" property, is no longer necessary. (So nothing new, except for "linux.elfcorehdr," will be invented.) But on the other hand, - arm64 and ppc do the different ways even though both are DT systems, - those reserved regions are still *in* linear mapping and appear as "System RAM" in /proc/iomem, and - this may imply that we cannot do kexec on crash dump kernel. -Takahiro AKASHI > Thanks, > -Takahiro AKASHI > > > Rob
Rob, On Wed, Aug 31, 2016 at 02:02:16PM +0900, AKASHI Takahiro wrote: > On Wed, Aug 31, 2016 at 08:45:46AM +0900, AKASHI Takahiro wrote: > > Rob, > > > > On Tue, Aug 30, 2016 at 11:34:10AM -0500, Rob Herring wrote: > > > On Sun, Aug 21, 2016 at 11:28 PM, AKASHI Takahiro > > > <takahiro.akashi@linaro.org> wrote: > > > > Rob, > > > > [Cc: Mark] > > > > > > > > On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: > > > >> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > > > >> > From: James Morse <james.morse@arm.com> > > > >> > > > > >> > Add documentation for > > > >> > linux,crashkernel-base and crashkernel-size, > > > >> > linux,usable-memory-range, and > > > >> > linux,elfcorehdr > > > >> > used by arm64 kexec/kdump to decribe the kdump reserved area, and > > > >> > the elfcorehdr's location within it. > > > >> > > > > >> > Signed-off-by: James Morse <james.morse@arm.com> > > > >> > [takahiro.akashi@linaro.org: > > > >> > renamed "usable-memory" to "usable-memory-range", > > > >> > added "linux,crashkernel-base" and "-size" ] > > > >> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > >> > --- > > > >> > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++ > > > >> > 1 file changed, 50 insertions(+) > > > >> > > > > >> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt > > > >> > index 6ae9d82..236188a 100644 > > > >> > --- a/Documentation/devicetree/bindings/chosen.txt > > > >> > +++ b/Documentation/devicetree/bindings/chosen.txt > > > >> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on > > > >> > book3e) by some versions of kexec-tools to tell the new kernel that it > > > >> > is being booted by kexec, as the booting environment may differ (e.g. > > > >> > a different secondary CPU release mechanism) > > > >> > + > > > >> > +linux,crashkernel-base > > > >> > +linux,crashkernel-size > > > >> > +---------------------- > > > >> > +These properties (currently used on PowerPC and arm64) indicates > > > >> > +the base address and the size, respectively, of the reserved memory > > > >> > +range for crash dump kernel. > > > >> > +e.g. > > > >> > + > > > >> > +/ { > > > >> > + chosen { > > > >> > + linux,crashkernel-base = <0x9 0xf0000000>; > > > >> > + linux,crashkernel-size = <0x0 0x10000000>; > > > >> > + }; > > > >> > +}; > > > >> > + > > > >> > +linux,usable-memory-range > > > >> > +------------------------- > > > >> > + > > > >> > +This property (currently used only on arm64) holds the memory range, > > > >> > +the base address and the size, which can be used as system ram on > > > >> > +the *current* kernel. Note that, if this property is present, any memory > > > >> > +regions under "memory" nodes in DT blob or ones marked as "conventional > > > >> > +memory" in EFI memory map should be ignored. > > > >> > +e.g. > > > >> > + > > > >> > +/ { > > > >> > + chosen { > > > >> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > > > >> > + }; > > > >> > +}; > > > >> > > > >> I've read the discussion on this. I think you should use the existing > > > >> linux,usable-memory property in the memory nodes. If UEFI systems don't > > > >> have memory nodes, then you can find an UEFI way to describe this. DT is > > > >> not the dumping ground for what doesn't fit in UEFI. How do x86 systems > > > >> work? > > > > > > > > Kdump for x86 passes the range of usable memory to crash dump kernel > > > > either via: > > > > (a) "memmap=nn@ss" command line parameter, or > > > > (b) faked BIOS e820 map (a sort of memory map table) > > > > > > > > (a) was rejected by Mark [1], and (b) is x86-specific. > > > > > > > > I believe that my approach is better because it works in the same way > > > > either on UEFI systems or DT-based systems. > > > > > > So we have a new way for both UEFI and DT. If UEFI folks can't come up > > > with a standard way to do things in the UEFI standard, then we just > > > dump them into DT? > > > > No, I don't think so. > > According to "Documentation/devicetree/bindings/chosen.txt, > > "The chosen node does not represent a real device, but serves as a place > > for passing data between firmware and the operating system, like boot > > arguments." > > > > Since kexec/dump is some sort of boot loader, it all makes sense to > > add a new property as an interface from the old kernel(kexec/dump) > > to the new kernel. So my approach doesn't break any DT rules. > > > > Please note that, even on UEFI/APCI systems, there are already a few > > properties used under /chosen, like "linux,uefi-system-table" and > > "linux,mmap-*." > > (Those properties are currently *not* defined in this document, though.) > > > > > I'd rather see alignment with existing DT systems > > > (PPC) and in particular the tools. > > > > I'm not sure what you mean here, but I guess: > > 1) On DT-only systems, we should follow the way that PPC does. > > (That is, adding "usable-memory" property to each "memory" node.) > > 2) On UEFI/ACPI system, we must invent a new own way for our purpose > > because, as I said before, there is no standard, but x86-specific way. > > > > Is this what you want to do? Yes? > > If so, > > do you agree to my approach of adding "linux,usable-memory-range" property > > to /chosen *for UEFI/ACPI use*? > > I've got another idea here: using "/memreserve/" field. We'd better to use "reserved-memory" node: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; crash_dump@80000000 { reg = <0x0 0x80000000 0x0 0x8000000>; no-map; } ... } so that we can clearly state that those regions are for kdump. Unfortunately, we can't place "reserved-memory" under /chosen. > All the memory regions used by the crashed kernel would be added > as "/memreserve/" and be memblock_reserve'd later in crash dump kernel. > Consequently, they will be excluded from the usable memory. > > Obviously, > - this approach will work both on UEFI/ACPI and DT-only systems, and > - patch#2 ("memblock: add memblock_cap_memory_range()"), as well as > "linux,usable-memory-range" property, is no longer necessary. > (So nothing new, except for "linux.elfcorehdr," will be invented.) > > But on the other hand, > - arm64 and ppc do the different ways even though both are DT systems, > - those reserved regions are still *in* linear mapping and appear as > "System RAM" in /proc/iomem, and > - this may imply that we cannot do kexec on crash dump kernel. If you never accept my approach of adding "linux,usable-memory-range," I will send a new version, v26, based on "reserved-memory" next week. (The only change is to remove patch#2/#3 from v25, though.) -Takahiro AKASHI > -Takahiro AKASHI > > > > Thanks, > > -Takahiro AKASHI > > > > > Rob
Hi Rob, Reviving an old thread -- "rock" and "hard place" come to mind. On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote: > On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote: > > From: James Morse <james.morse@arm.com> > > +linux,usable-memory-range > > +------------------------- > > + > > +This property (currently used only on arm64) holds the memory range, > > +the base address and the size, which can be used as system ram on > > +the *current* kernel. Note that, if this property is present, any memory > > +regions under "memory" nodes in DT blob or ones marked as "conventional > > +memory" in EFI memory map should be ignored. > > +e.g. > > + > > +/ { > > + chosen { > > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; > > + }; > > +}; > > I've read the discussion on this. I think you should use the existing > linux,usable-memory property in the memory nodes. If UEFI systems don't > have memory nodes, then you can find an UEFI way to describe this. DT is > not the dumping ground for what doesn't fit in UEFI. How do x86 systems > work? Having looked at the proposals, I'm personally much keener on the approach above (modulo naming and wording) than trying to bolt memory nodes onto a UEFI system, or using reserved-memory to describe the inverse of the allowable range. I completely agree that we want one solution for DT-only and DT+UEFI. While those approaches reuse existing infrastructure, they end up creating more work, and I believe that they create more scope for painful problems. As kdump is already a constrained case, I think that it's reasonable to have a linux-specific property as above. I also think we need to figure out how we expect this to work for the kexec_file_load case, as that has a criticial impact on the above (e.g. what's preferable out of cmdline options vs dt properties). Can we try to sync at connect to discuss this? Thanks, Mark.
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index 6ae9d82..236188a 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on book3e) by some versions of kexec-tools to tell the new kernel that it is being booted by kexec, as the booting environment may differ (e.g. a different secondary CPU release mechanism) + +linux,crashkernel-base +linux,crashkernel-size +---------------------- +These properties (currently used on PowerPC and arm64) indicates +the base address and the size, respectively, of the reserved memory +range for crash dump kernel. +e.g. + +/ { + chosen { + linux,crashkernel-base = <0x9 0xf0000000>; + linux,crashkernel-size = <0x0 0x10000000>; + }; +}; + +linux,usable-memory-range +------------------------- + +This property (currently used only on arm64) holds the memory range, +the base address and the size, which can be used as system ram on +the *current* kernel. Note that, if this property is present, any memory +regions under "memory" nodes in DT blob or ones marked as "conventional +memory" in EFI memory map should be ignored. +e.g. + +/ { + chosen { + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; + }; +}; + +The main usage is for crash dump kernel to identify its own usable +memory and exclude, at its boot time, any other memory areas that are +part of the panicked kernel's memory. + +linux,elfcorehdr +---------------- + +This property (currently used only on arm64) holds the memory range, +the address and the size, of the elf core header which mainly describes +the panicked kernel's memory layout in elf format. +e.g. + +/ { + chosen { + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; + linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>; + }; +};