----- Original Message ----- > > > > On Fri, May 30, 2014 at 2:32 AM, Dave Anderson < anderson@xxxxxxxxxx > wrote: > > > > > > ----- Original Message ----- > > > > > > > > On Fri, May 30, 2014 at 12:36 AM, Dave Anderson < anderson@xxxxxxxxxx > > > wrote: > > > > > > > > > > > > ----- Original Message ----- > > > hi, > > > > > > i dump the whole memory of a KVM guest out using "dump-guest-memory". as a > > > result, now i have a big ELF file. i want to use "crash" to analyze this dump file. > > > > > > the question is: given the RIP address of an instruction in the KVM guest > > > - > > > for example 0x12345, which is virtual address, how can "crash" tell me where > > > in the dump is the position of 0x12345? is there such a command for this? > > > > Is the RIP in user-space or kernel-space? If I understand your question correctly, > > you can enter "vtop" of the RIP to get the physical address, but if it's a > > user-space address, you must ensure that you have "set" the context to the > > PID/task-address of the task whose user-space memory you want to look at. > > > > > > > > my intention is to locate the place, and analyze the assembly instruction > > > around that RIP to see what is running at the time i dumped the KVM > > > memory. > > > > You really don't need to know where in the dumpfile the RIP is located > > for disassembly. If it's kernel-space you're interested in, then you > > can just do "dis -rl <RIP-address>" to see the sequence of instructions > > leading up to the RIP. If it's user-space, there's no way to determine > > the beginning of the user-space function that was running, so the best > > you can do is to "set" your context to the task you're interested in, > > and do a "dis -u <user-space-RIP> <count>" to see where it was, and where > > it would be going to. > > > > > > yes, the RIP is in the kernel at that time. > > > > could you please confirm that everything you said above work with all kind of > > guest OS running on x86, but not only Linux guest? > > Sorry, no, the crash utility will only work with a Linux guest. > > oh, but i understand that for commands like "vtop", the guest OS doesnt > really matter, because how OS organizes its memory doesnt really depend on > OS, right? Knowledge of the guest kernel is required to find the location of the starting page directory address of the kernel virtual address space, or of each user-space task. > this is because the way virtual memory is mapped to physical memory address > is defined by x86 hardware, but not by the OS itself. > > (i would understand that there are not many commands that are OS-independent > like "vtop") Perhaps, but the crash utility only works with vmlinux kernels. Actually it also works with Xen hypervisor binaries, which account for all of the xen_hyper_xxx.[ch] files in the crash sources. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility