From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI Takahiro) Date: Thu, 29 Oct 2015 14:55:06 +0900 Subject: [PATCH 13/16] arm64: kdump: add kdump support In-Reply-To: <20151023095059.GH11227@dhcp-129-115.nay.redhat.com> References: <20151022032534.GC11227@dhcp-129-115.nay.redhat.com> <5628662B.1020605@linaro.org> <20151022051548.GD11227@dhcp-129-115.nay.redhat.com> <5628B2FA.80209@linaro.org> <20151023095059.GH11227@dhcp-129-115.nay.redhat.com> Message-ID: <5631B4BA.6030903@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Dave, On 10/23/2015 06:50 PM, Dave Young wrote: > On 10/22/15 at 06:57pm, AKASHI Takahiro wrote: >> (added Ard to Cc.) >> >> On 10/22/2015 02:15 PM, Dave Young wrote: >>> On 10/22/15 at 01:29pm, AKASHI Takahiro wrote: >>>> Hi Dave, >>>> >>>> Thank you for your comment. >>>> >>>> On 10/22/2015 12:25 PM, Dave Young wrote: >>>>> Hi, AKASHI, >>>>> >>>>> On 10/19/15 at 11:38pm, Geoff Levand wrote: >>>>>> From: AKASHI Takahiro >>>>>> >>>>>> On crash dump kernel, all the information about primary kernel's core >>>>>> image is available in elf core header specified by "elfcorehdr=" boot >>>>>> parameter. reserve_elfcorehdr() will set aside the region to avoid any >>>>>> corruption by crash dump kernel. >>>>>> >>>>>> Crash dump kernel will access the system memory of primary kernel via >>>>>> copy_oldmem_page(), which reads one page by ioremap'ing it since it does >>>>>> not reside in linear mapping on crash dump kernel. >>>>>> Please note that we should add "mem=X[MG]" boot parameter to limit the >>>>>> memory size and avoid the following assertion at ioremap(): >>>>>> if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) >>>>>> return NULL; >>>>>> when accessing any pages beyond the usable memories of crash dump kernel. >>>>> >>>>> How does kexec-tools pass usable memory ranges to kernel? using dtb? >>>>> Passing an extra mem=X sounds odd in the design. Kdump kernel should get >>>>> usable ranges and hanle the limit better than depending on an extern kernel >>>>> param. >>>> >>>> Well, regarding "depending on an external kernel param," >>>> - this limitation ("mem=") is compatible with arm(32) implementation although >>>> it is not clearly described in kernel's Documentation/kdump/kdump.txt. >>>> - "elfcorehdr" kernel parameter is mandatory on x86 as well as on arm/arm64. >>>> The parameter is explicitly generated and added by kexec-tools. >>>> >>>> Do I miss your point? >>> >>> Arm previously use atag_mem tag for memory kernel uses, with dtb, Booting.txt >>> says: The boot loader must pass at a minimum the size and location of the >>> system memory >>> >>> In arm64 booting.txt, it does mentions about dtb but without above sentence. >>> >>> So if you are using dtb to pass memory I think the extra mem= should be not >>> necessary unless there's other limitations dtb can not been used. >> >> I would expect comments from arm64 maintainers here. >> >> In my old implementation, I added "usablemem" attributes, along with "reg," to >> "memory" nodes in dtb to specify the usable memory region on crash dump kernel. >> >> But I removed this feature partly because, on uefi system, uefi might pass >> no memory information in dtb. > > If this is the case there must be somewhere else one can pass memory infomation > to kernel, the booting.txt should be updated? > > kexec as a boot loader need use same method as the 1st kernel boot loader. > >> >>> One thing I'm confused is mem= only pass the memory size, where does you pass >>> the start addresses? >> >> In the current arm64 implementation, any regions below the start address will >> be ignored as system ram. >> >>> What if there's multiple sections such as some reserved >>> ranges 2nd kernel also need? >> >> My patch utilizes only a single contiguous region of memory as system ram. >> One exception that I notice is uefi's runtime data. They will be ioremap'ed separately. >> >> Please let me know if there is any other case that should be supported. > > For example the elf headers range, you reserved them in kdump kernel code, > but kexec-tools can do that early if it can provides all memory info to 2nd > kernel. Ditto for mark all the memory ranges 1st kernel used as reserved. It seems to me that the issue you mentioned here is totally independent from "mem=" issue, isn't it? (and "elfcorehdr=" is a common way for crash dump kernel to know the region.) -Takahiro AKASHI > Thanks > Dave > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZrgBS-0002P0-I1 for kexec@lists.infradead.org; Thu, 29 Oct 2015 05:55:35 +0000 Received: by pacfv9 with SMTP id fv9so31284783pac.3 for ; Wed, 28 Oct 2015 22:55:13 -0700 (PDT) Subject: Re: [PATCH 13/16] arm64: kdump: add kdump support References: <20151022032534.GC11227@dhcp-129-115.nay.redhat.com> <5628662B.1020605@linaro.org> <20151022051548.GD11227@dhcp-129-115.nay.redhat.com> <5628B2FA.80209@linaro.org> <20151023095059.GH11227@dhcp-129-115.nay.redhat.com> From: AKASHI Takahiro Message-ID: <5631B4BA.6030903@linaro.org> Date: Thu, 29 Oct 2015 14:55:06 +0900 MIME-Version: 1.0 In-Reply-To: <20151023095059.GH11227@dhcp-129-115.nay.redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Dave Young Cc: Mark Rutland , AKASHI@infradead.org, ard.biesheuvel@linaro.org, Geoff Levand , Catalin Marinas , Will Deacon , marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, christoffer.dall@linaro.org Dave, On 10/23/2015 06:50 PM, Dave Young wrote: > On 10/22/15 at 06:57pm, AKASHI Takahiro wrote: >> (added Ard to Cc.) >> >> On 10/22/2015 02:15 PM, Dave Young wrote: >>> On 10/22/15 at 01:29pm, AKASHI Takahiro wrote: >>>> Hi Dave, >>>> >>>> Thank you for your comment. >>>> >>>> On 10/22/2015 12:25 PM, Dave Young wrote: >>>>> Hi, AKASHI, >>>>> >>>>> On 10/19/15 at 11:38pm, Geoff Levand wrote: >>>>>> From: AKASHI Takahiro >>>>>> >>>>>> On crash dump kernel, all the information about primary kernel's core >>>>>> image is available in elf core header specified by "elfcorehdr=" boot >>>>>> parameter. reserve_elfcorehdr() will set aside the region to avoid any >>>>>> corruption by crash dump kernel. >>>>>> >>>>>> Crash dump kernel will access the system memory of primary kernel via >>>>>> copy_oldmem_page(), which reads one page by ioremap'ing it since it does >>>>>> not reside in linear mapping on crash dump kernel. >>>>>> Please note that we should add "mem=X[MG]" boot parameter to limit the >>>>>> memory size and avoid the following assertion at ioremap(): >>>>>> if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) >>>>>> return NULL; >>>>>> when accessing any pages beyond the usable memories of crash dump kernel. >>>>> >>>>> How does kexec-tools pass usable memory ranges to kernel? using dtb? >>>>> Passing an extra mem=X sounds odd in the design. Kdump kernel should get >>>>> usable ranges and hanle the limit better than depending on an extern kernel >>>>> param. >>>> >>>> Well, regarding "depending on an external kernel param," >>>> - this limitation ("mem=") is compatible with arm(32) implementation although >>>> it is not clearly described in kernel's Documentation/kdump/kdump.txt. >>>> - "elfcorehdr" kernel parameter is mandatory on x86 as well as on arm/arm64. >>>> The parameter is explicitly generated and added by kexec-tools. >>>> >>>> Do I miss your point? >>> >>> Arm previously use atag_mem tag for memory kernel uses, with dtb, Booting.txt >>> says: The boot loader must pass at a minimum the size and location of the >>> system memory >>> >>> In arm64 booting.txt, it does mentions about dtb but without above sentence. >>> >>> So if you are using dtb to pass memory I think the extra mem= should be not >>> necessary unless there's other limitations dtb can not been used. >> >> I would expect comments from arm64 maintainers here. >> >> In my old implementation, I added "usablemem" attributes, along with "reg," to >> "memory" nodes in dtb to specify the usable memory region on crash dump kernel. >> >> But I removed this feature partly because, on uefi system, uefi might pass >> no memory information in dtb. > > If this is the case there must be somewhere else one can pass memory infomation > to kernel, the booting.txt should be updated? > > kexec as a boot loader need use same method as the 1st kernel boot loader. > >> >>> One thing I'm confused is mem= only pass the memory size, where does you pass >>> the start addresses? >> >> In the current arm64 implementation, any regions below the start address will >> be ignored as system ram. >> >>> What if there's multiple sections such as some reserved >>> ranges 2nd kernel also need? >> >> My patch utilizes only a single contiguous region of memory as system ram. >> One exception that I notice is uefi's runtime data. They will be ioremap'ed separately. >> >> Please let me know if there is any other case that should be supported. > > For example the elf headers range, you reserved them in kdump kernel code, > but kexec-tools can do that early if it can provides all memory info to 2nd > kernel. Ditto for mark all the memory ranges 1st kernel used as reserved. It seems to me that the issue you mentioned here is totally independent from "mem=" issue, isn't it? (and "elfcorehdr=" is a common way for crash dump kernel to know the region.) -Takahiro AKASHI > Thanks > Dave > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec