----- Original Message -----
> Hi
> vmemmap and VMEMMAP_START are different,vmemmap begin from physical address
> 0x0 of page,but VMEMMAP_START start with memstart_addr.
>
> [mm/init.c]
> arm64_memblock_init
> 348 vmemmap = ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT));
Right, so VMEMMAP_START can be calculated by reading vmemmap and memstart_addr.
>
> We can look at address_markers, this symbol indicates the entire memory map allocation
> check vmemmap and address_markers, we can see vmemmap has out of vmemmap range
It would be ideal if address_markers was guaranteed to be there, but it
only exists if CONFIG_PTDUMP_CORE was configured.
> crash> p -x vmemmap
> vmemmap = $1 = (struct page *) 0xfffffffefde00000
>
> address_markers = $2 =
> {{
> start_address = 0xffffff8000000000,
> name = 0xffffffd44b1fed8f "Linear Mapping start"
> ...
> }, {
> start_address = 0xfffffffeffe00000,
> name = 0xffffffd44b2c5beb "vmemmap start"
> }, {
> start_address = 0xffffffffffe00000,
> name = 0xffffffd44b1eb00c "vmemmap end"
> }, {
> start_address = 0xffffffffffffffff,
> name = 0x0
> }}
>
>
> > When the readmem() of symbol_value("physvirt_offset") is made, arm64_VTOP() will
> > be called with its virtual address, right?
> Yes, arm64_VTOP to get physvirt_offset needs virtual address, and
> physvirt_offset is a kimage symbol,so just need kimage_voffset can translate
> to physical address,then get value of physvirt_offset.
Ah, you're right, it's a mapped kernel symbol and doesn't use it.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
