From: Michael Holzheu <holzheu@linux.vnet.ibm.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: Zhang Yanfei <zhangyanfei.yes@gmail.com>, "Eric W. Biederman" <ebiederm@xmission.com>, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, Jan Willeke <willeke@de.ibm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390 Date: Wed, 29 May 2013 13:51:44 +0200 [thread overview] Message-ID: <20130529135144.7f95c4c0@holzheu> (raw) In-Reply-To: <20130528135500.GC7088@redhat.com> On Tue, 28 May 2013 09:55:01 -0400 Vivek Goyal <vgoyal@redhat.com> wrote: > On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote: [snip] > > Besides of the newmem mechanism, for completeness, we also > > implemented the oldmem ELF header mechansim in kexec. But this is > > disabled by default. > > > > See: "#ifdef WITH_ELF_HEADER" in kexec/arch/s390/crashdump-s390.c > > > > Currently no distribution uses the oldmem mechanism. > > Hi Michael, > > Mechanism to read from newmem is not there yet (your patches are still > being reviewed) and you mentioned that no distribution is building > kexec-tools with WITH_ELF_HEADER on s390. So how things are currently > working for kdump on s390? Hello Vivek, On s390, if we do not get the ELF header from the 1st kernel with "elfcorehdr=", we build the ELF header in the 2nd kernel. This is currently the default because WITH_ELF_HEADER is not defined for kexec tools. >>> START QUOTE [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature Currently for s390 we create the ELF core header in the 2nd kernel with a small trick. We relocate the addresses in the ELF header in a way that for the /proc/vmcore code it seems to be in the 1st kernel (old) memory and the read_from_oldmem() returns the correct data. This allows the /proc/vmcore code to use the ELF header in the 2nd kernel. >>> END QUOTE For our current zfcpdump project (see "[PATCH 3/3]s390/kdump: Use vmcore for zfcpdump") we could no longer use this trick. Therefore we sent you the patches to get a clean interface for ELF header creation in the 2nd kernel. > > > > Therefore, if necessary, IMHO we can switch to the ELF header memory > > swap mechanism for s390 in the kernel. Of course we would then also > > have to adjust the (disabled) kexec code. > > So are you saying that s390 is ready to switch to mechanism of > creating ELF headers in first kernel by kexec-tools and new kernel > does not have to preare ELF headers? No, I meant that currently nobody is using the kexec tools ELF header creation in the 1st kernel on s390. We create the ELF header in the 2nd kernel (mainly because of our cpuplugd issue). Therefore, I think, we can safely change the ELF header creation in 2nd kernel to use your p_offset swap trick *and* we remove the swap code in the copy_oldmem_page() implementation (same kernel). Best Regards, Michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Holzheu <holzheu@linux.vnet.ibm.com> To: Vivek Goyal <vgoyal@redhat.com> Cc: kexec@lists.infradead.org, Heiko Carstens <heiko.carstens@de.ibm.com>, Jan Willeke <willeke@de.ibm.com>, linux-kernel@vger.kernel.org, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, Zhang Yanfei <zhangyanfei.yes@gmail.com> Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390 Date: Wed, 29 May 2013 13:51:44 +0200 [thread overview] Message-ID: <20130529135144.7f95c4c0@holzheu> (raw) In-Reply-To: <20130528135500.GC7088@redhat.com> On Tue, 28 May 2013 09:55:01 -0400 Vivek Goyal <vgoyal@redhat.com> wrote: > On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote: [snip] > > Besides of the newmem mechanism, for completeness, we also > > implemented the oldmem ELF header mechansim in kexec. But this is > > disabled by default. > > > > See: "#ifdef WITH_ELF_HEADER" in kexec/arch/s390/crashdump-s390.c > > > > Currently no distribution uses the oldmem mechanism. > > Hi Michael, > > Mechanism to read from newmem is not there yet (your patches are still > being reviewed) and you mentioned that no distribution is building > kexec-tools with WITH_ELF_HEADER on s390. So how things are currently > working for kdump on s390? Hello Vivek, On s390, if we do not get the ELF header from the 1st kernel with "elfcorehdr=", we build the ELF header in the 2nd kernel. This is currently the default because WITH_ELF_HEADER is not defined for kexec tools. >>> START QUOTE [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature Currently for s390 we create the ELF core header in the 2nd kernel with a small trick. We relocate the addresses in the ELF header in a way that for the /proc/vmcore code it seems to be in the 1st kernel (old) memory and the read_from_oldmem() returns the correct data. This allows the /proc/vmcore code to use the ELF header in the 2nd kernel. >>> END QUOTE For our current zfcpdump project (see "[PATCH 3/3]s390/kdump: Use vmcore for zfcpdump") we could no longer use this trick. Therefore we sent you the patches to get a clean interface for ELF header creation in the 2nd kernel. > > > > Therefore, if necessary, IMHO we can switch to the ELF header memory > > swap mechanism for s390 in the kernel. Of course we would then also > > have to adjust the (disabled) kexec code. > > So are you saying that s390 is ready to switch to mechanism of > creating ELF headers in first kernel by kexec-tools and new kernel > does not have to preare ELF headers? No, I meant that currently nobody is using the kexec tools ELF header creation in the 1st kernel on s390. We create the ELF header in the 2nd kernel (mainly because of our cpuplugd issue). Therefore, I think, we can safely change the ELF header creation in 2nd kernel to use your p_offset swap trick *and* we remove the swap code in the copy_oldmem_page() implementation (same kernel). Best Regards, Michael _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-05-29 11:51 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-24 13:08 [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390 Michael Holzheu 2013-05-24 13:08 ` Michael Holzheu 2013-05-24 13:08 ` [PATCH 1/2] kdump/mmap: Introduce arch_oldmem_remap_pfn_range() Michael Holzheu 2013-05-24 13:08 ` Michael Holzheu 2013-05-24 13:08 ` [PATCH 2/2] s390/kdump/mmap: Implement arch_oldmem_remap_pfn_range() for s390 Michael Holzheu 2013-05-24 13:08 ` Michael Holzheu 2013-05-24 14:36 ` [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore " Vivek Goyal 2013-05-24 14:36 ` Vivek Goyal 2013-05-24 15:06 ` Michael Holzheu 2013-05-24 15:06 ` Michael Holzheu 2013-05-24 15:28 ` Vivek Goyal 2013-05-24 15:28 ` Vivek Goyal 2013-05-24 16:46 ` Michael Holzheu 2013-05-24 16:46 ` Michael Holzheu 2013-05-24 17:05 ` Vivek Goyal 2013-05-24 17:05 ` Vivek Goyal 2013-05-25 13:13 ` Michael Holzheu 2013-05-25 13:13 ` Michael Holzheu 2013-05-24 22:44 ` Eric W. Biederman 2013-05-24 22:44 ` Eric W. Biederman 2013-05-25 0:33 ` Zhang Yanfei 2013-05-25 0:33 ` Zhang Yanfei 2013-05-25 3:01 ` Eric W. Biederman 2013-05-25 3:01 ` Eric W. Biederman 2013-05-25 8:31 ` Zhang Yanfei 2013-05-25 8:31 ` Zhang Yanfei 2013-05-25 12:52 ` Michael Holzheu 2013-05-25 12:52 ` Michael Holzheu 2013-05-28 13:55 ` Vivek Goyal 2013-05-28 13:55 ` Vivek Goyal 2013-05-29 11:51 ` Michael Holzheu [this message] 2013-05-29 11:51 ` Michael Holzheu 2013-05-29 16:23 ` Vivek Goyal 2013-05-29 16:23 ` Vivek Goyal 2013-05-29 17:12 ` Michael Holzheu 2013-05-29 17:12 ` Michael Holzheu 2013-05-30 15:00 ` Vivek Goyal 2013-05-30 15:00 ` Vivek Goyal 2013-05-30 20:38 ` Vivek Goyal 2013-05-30 20:38 ` Vivek Goyal 2013-05-31 14:21 ` Michael Holzheu 2013-05-31 14:21 ` Michael Holzheu 2013-05-31 16:01 ` Vivek Goyal 2013-05-31 16:01 ` Vivek Goyal 2013-06-03 13:27 ` Michael Holzheu 2013-06-03 13:27 ` Michael Holzheu 2013-06-03 15:59 ` Vivek Goyal 2013-06-03 15:59 ` Vivek Goyal 2013-06-03 16:48 ` Michael Holzheu 2013-06-03 16:48 ` Michael Holzheu 2013-05-28 14:44 ` Vivek Goyal 2013-05-28 14:44 ` Vivek Goyal 2013-05-25 20:36 ` Eric W. Biederman 2013-05-25 20:36 ` Eric W. Biederman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130529135144.7f95c4c0@holzheu \ --to=holzheu@linux.vnet.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=d.hatayama@jp.fujitsu.com \ --cc=ebiederm@xmission.com \ --cc=heiko.carstens@de.ibm.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=schwidefsky@de.ibm.com \ --cc=vgoyal@redhat.com \ --cc=willeke@de.ibm.com \ --cc=zhangyanfei.yes@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.