All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Dave Anderson <anderson@redhat.com>
Cc: panand@redhat.com, keescook@chromium.org,
	ats-kumagai@wm.jp.nec.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	takahiro akashi <takahiro.akashi@linaro.org>,
	mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
	tglx@linutronix.de, Dave Young <dyoung@redhat.com>,
	thgarnie@google.com, tonli@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Wed, 2 Nov 2016 09:34:33 +0800	[thread overview]
Message-ID: <20161102013433.GA3928@x1> (raw)
In-Reply-To: <115590076.11735656.1478009614692.JavaMail.zimbra@redhat.com>

Hi Dave,

On 11/01/16 at 10:13am, Dave Anderson wrote:
> 
> 
> > > But we have this in mainline which also introduced the VMCOREINFO
> > > numbers, can you send a patch to revert them?
> > 
> > OK, will do.
> > 
> > However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
> > still needed. I checked code, seems no better way to avoid. I am not
> > sure how many people are really using "-e" option to exclude unused
> > vmemmap pages.
> > 
> > Maybe just leave it as is, and fix it when people complain?
> 
> Speaking of complaints, is there any chance you can make the
> x86_64 "phys_base" value available?  The VMCOREINFO_SYMBOL(phys_base)
> is useless since its contents are needed in order to access the
> symbol address.

Yeah, the current exporting of virt addr of phys_base is really useless
for x86_64. While I saw you have got phys_base from kdump-ed vmcore elf
program header since kexec-tools has created that pt_load for kernel text
region.

machdep->machspec->phys_base = phdr->p_paddr - (phdr->p_vaddr & ~(__START_KERNEL_map));

Do you still want the value of phys_base? If yes, I can change it to
export the real value of phys_base, not &phys_base.

In fact, exporting &phys_base was done in 2008, makedumpfile has taken
the similar way you use in crash to get value of phys_base. Means it has
been ignored very earlier. You could be the first person to complain
about it.

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Dave Anderson <anderson@redhat.com>
Cc: Dave Young <dyoung@redhat.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	keescook@chromium.org, ats-kumagai@wm.jp.nec.com,
	thgarnie@google.com, takahiro akashi <takahiro.akashi@linaro.org>,
	mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com,
	tglx@linutronix.de, akpm@linux-foundation.org, tonli@redhat.com,
	panand@redhat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Wed, 2 Nov 2016 09:34:33 +0800	[thread overview]
Message-ID: <20161102013433.GA3928@x1> (raw)
In-Reply-To: <115590076.11735656.1478009614692.JavaMail.zimbra@redhat.com>

Hi Dave,

On 11/01/16 at 10:13am, Dave Anderson wrote:
> 
> 
> > > But we have this in mainline which also introduced the VMCOREINFO
> > > numbers, can you send a patch to revert them?
> > 
> > OK, will do.
> > 
> > However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
> > still needed. I checked code, seems no better way to avoid. I am not
> > sure how many people are really using "-e" option to exclude unused
> > vmemmap pages.
> > 
> > Maybe just leave it as is, and fix it when people complain?
> 
> Speaking of complaints, is there any chance you can make the
> x86_64 "phys_base" value available?  The VMCOREINFO_SYMBOL(phys_base)
> is useless since its contents are needed in order to access the
> symbol address.

Yeah, the current exporting of virt addr of phys_base is really useless
for x86_64. While I saw you have got phys_base from kdump-ed vmcore elf
program header since kexec-tools has created that pt_load for kernel text
region.

machdep->machspec->phys_base = phdr->p_paddr - (phdr->p_vaddr & ~(__START_KERNEL_map));

Do you still want the value of phys_base? If yes, I can change it to
export the real value of phys_base, not &phys_base.

In fact, exporting &phys_base was done in 2008, makedumpfile has taken
the similar way you use in crash to get value of phys_base. Means it has
been ignored very earlier. You could be the first person to complain
about it.

Thanks
Baoquan

  reply	other threads:[~2016-11-02  1:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06  8:46 [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo Baoquan He
2016-10-06  8:46 ` Baoquan He
2016-10-06 20:07 ` Eric W. Biederman
2016-10-06 20:07   ` Eric W. Biederman
2016-10-11  7:41   ` Baoquan He
2016-10-11  7:41     ` Baoquan He
2016-10-11  8:19     ` Dave Young
2016-10-11  8:19       ` Dave Young
2016-10-11  8:43       ` Dave Young
2016-10-11  8:43         ` Dave Young
2016-10-12  0:26       ` Baoquan He
2016-10-12  0:26         ` Baoquan He
2016-10-12  9:09         ` Pratyush Anand
2016-10-12  9:09           ` Pratyush Anand
2016-10-13  8:53           ` Baoquan He
2016-10-13  8:53             ` Baoquan He
2016-10-14  3:13             ` Dave Young
2016-10-14  3:13               ` Dave Young
2016-11-01  5:10 ` Dave Young
2016-11-01  5:10   ` Dave Young
2016-11-01  5:33   ` Baoquan He
2016-11-01  5:33     ` Baoquan He
2016-11-01 14:13     ` Dave Anderson
2016-11-01 14:13       ` Dave Anderson
2016-11-02  1:34       ` Baoquan He [this message]
2016-11-02  1:34         ` Baoquan He
2016-11-02 13:29         ` Dave Anderson
2016-11-02 13:29           ` Dave Anderson
2016-11-02 13:48           ` Baoquan He
2016-11-02 13:48             ` Baoquan He

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=20161102013433.GA3928@x1 \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anderson@redhat.com \
    --cc=ats-kumagai@wm.jp.nec.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=panand@redhat.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=tonli@redhat.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: link
Be 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.