----- 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