On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
[...]
> > > (This is the reason that I don't think we need a VMCOREINFO for
> > > CONFIG_RANDOMIZE_BASE.)
> >
> > Well, as long as there's a way to avoid that unnecessary/confusing
> > warning message for non-KASLR new-vmemmap kernels.
> >
> > I also wonder whether makedumpfile could use it?
>
> -> Pratyush?
Since second kernel's initrd cannot include a large file like VMLINUX, so
makedumpfile should also work without passing '-x vmlinux'. Therefore,
makedumpfile will need some minimal symbol's values to be passed in vmcore.
I understand.
(but I wonder why makedumpfile doesn't utilize System.map nor .config.)
IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to
calculate
PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
No, as I said in the discussions, I don't think that we need
CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
from /proc/vmcore.
Following numbers in vmcore [1] is helping me out in implementing
__pa() and
__va() for all page table sizes and levels.
VMCOREINFO_NUMBER(pgtable_levels);
VMCOREINFO_NUMBER(va_bits);
VMCOREINFO_NUMBER(page_shift);
Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
As well, pgtable_levels can be determined by va_bits and PAGESIZE.
See arch/arm64/Kconfig.
VMCOREINFO_NUMBER(phys_offset);
VMCOREINFO_NUMBER(config_kasan);
Let me ask some questions.
* What kind of data in vmcore and how does makedumpfile access
without vmlinux nor System.map?
* Why do you need CONFIG_KASAN?
Thanks,
-Takahiro AKASHI
--
Thanks,
-Takahiro AKASHI