[libvirt-users] Understanding the contents of virsh dump --memory-only
Hello, I was trying to understand the ELF file generated by the virsh dump (--memory-only) command. I have successfully generated a dump of the VM memory using this command. I specifically am trying to understand the loadable segments of this ELF file. I ran readelf -a <filename> to get the information that I need. Below shows the details of the loadable segments in a much better format :- Loading ELF header #1. offset: 1320 filesize: 655360 memsize: 655360 vaddr: 0 paddr: 0 align: 0 flags: 0 Loading ELF header #2. offset: 656680 filesize: 65536 memsize: 65536 vaddr: 0 paddr: a0000 align: 0 flags: 0 Loading ELF header #3. offset: 722216 filesize: 1072955392 memsize: 1072955392 vaddr: 0 paddr: c0000 align: 0 flags: 0 Loading ELF header #4. offset: 1073677608 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f4000000 align: 0 flags: 0 Loading ELF header #5. offset: 1140786472 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f8000000 align: 0 flags: 0 Loading ELF header #6. offset: 1207895336 filesize: 8192 memsize: 8192 vaddr: 0 paddr: fc054000 align: 0 flags: 0 Loading ELF header #7. offset: 1207903528 filesize: 262144 memsize: 262144 vaddr: 0 paddr: fffc0000 align: 0 flags: 0 I wanted to know why in this case, is the virtual address (denoted by vaddr) 0 for each of the loadable segments ? Will it be okay if I load the elf file taking the values of physical address (denoted by paddr) into account ? Specifically after loading the file, can I be certain that all of my contents will have been loaded into memory address starting from 0 ? Will the loaded contents be present in the exact location as specified (by paddr) here ? Thanks and Regards. Arnab
On Tue, Aug 01, 2017 at 10:22:43PM -0400, Arnabjyoti Kalita wrote:
Hello,
I was trying to understand the ELF file generated by the virsh dump (--memory-only) command. I have successfully generated a dump of the VM memory using this command.
You are running a QEMU machine and the dump is generated by qemu, so they would be able to explain to much further detail, I'm sure. Anyway, here goes my try.
I specifically am trying to understand the loadable segments of this ELF file.
I ran readelf -a <filename> to get the information that I need. Below shows the details of the loadable segments in a much better format :-
Loading ELF header #1. offset: 1320 filesize: 655360 memsize: 655360 vaddr: 0 paddr: 0 align: 0 flags: 0 Loading ELF header #2. offset: 656680 filesize: 65536 memsize: 65536 vaddr: 0 paddr: a0000 align: 0 flags: 0 Loading ELF header #3. offset: 722216 filesize: 1072955392 memsize: 1072955392 vaddr: 0 paddr: c0000 align: 0 flags: 0 Loading ELF header #4. offset: 1073677608 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f4000000 align: 0 flags: 0 Loading ELF header #5. offset: 1140786472 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f8000000 align: 0 flags: 0 Loading ELF header #6. offset: 1207895336 filesize: 8192 memsize: 8192 vaddr: 0 paddr: fc054000 align: 0 flags: 0 Loading ELF header #7. offset: 1207903528 filesize: 262144 memsize: 262144 vaddr: 0 paddr: fffc0000 align: 0 flags: 0
Just to be clear, this is the memory of the machine with kernel and several other things loaded. I'm not sure what are all the segments, but since the dump acts as something you can use to debug the guest OS using the crash utility, which is somehow enhanced gdb for this purpose, IIRC, then I guess it's the MMU mapping of everything in the guest OS.
I wanted to know why in this case, is the virtual address (denoted by vaddr) 0 for each of the loadable segments ? Will it be okay if I load the elf file taking the values of physical address (denoted by paddr) into account ?
My guess is that those are the addresses from the MMU. Each segment has it's own vaddr <-> paddr mapping.
Specifically after loading the file, can I be certain that all of my contents will have been loaded into memory address starting from 0 ? Will the loaded contents be present in the exact location as specified (by paddr) here ?
It depends on what you mean by loading. You wouldn't be starting that binary as any other program, it's rather a dump as you would have with a coredump. Physical address is probably just the location in the guest machine, so the thing with paddr 0 would be seabios or something BIOS-related, etc. If you want precise answers and not guesses, I would suggest the qemu mailing list or any other related list. libvirt is not the best choice here unless someone from the other communities replies here. HTH, Martin
Thanks and Regards. Arnab
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Hi Martin, Thanks for your answer! I had 7 PT_LOAD segments -- each of which are being shown above in my formatted readelf output. All of the 7 PT_LOAD segments had a virtual address of 0 and some 4 KB aligned physical address. Anyway I will try to ask the same query in the QEMU mailing list. On Wed, Aug 2, 2017 at 7:55 AM, Martin Kletzander <mkletzan@redhat.com> wrote:
On Tue, Aug 01, 2017 at 10:22:43PM -0400, Arnabjyoti Kalita wrote:
Hello,
I was trying to understand the ELF file generated by the virsh dump (--memory-only) command. I have successfully generated a dump of the VM memory using this command.
You are running a QEMU machine and the dump is generated by qemu, so they would be able to explain to much further detail, I'm sure. Anyway, here goes my try.
I specifically am trying to understand the loadable segments of this ELF
file.
I ran readelf -a <filename> to get the information that I need. Below shows the details of the loadable segments in a much better format :-
Loading ELF header #1. offset: 1320 filesize: 655360 memsize: 655360 vaddr: 0 paddr: 0 align: 0 flags: 0 Loading ELF header #2. offset: 656680 filesize: 65536 memsize: 65536 vaddr: 0 paddr: a0000 align: 0 flags: 0 Loading ELF header #3. offset: 722216 filesize: 1072955392 memsize: 1072955392 vaddr: 0 paddr: c0000 align: 0 flags: 0 Loading ELF header #4. offset: 1073677608 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f4000000 align: 0 flags: 0 Loading ELF header #5. offset: 1140786472 filesize: 67108864 memsize: 67108864 vaddr: 0 paddr: f8000000 align: 0 flags: 0 Loading ELF header #6. offset: 1207895336 filesize: 8192 memsize: 8192 vaddr: 0 paddr: fc054000 align: 0 flags: 0 Loading ELF header #7. offset: 1207903528 filesize: 262144 memsize: 262144 vaddr: 0 paddr: fffc0000 align: 0 flags: 0
Just to be clear, this is the memory of the machine with kernel and several other things loaded. I'm not sure what are all the segments, but since the dump acts as something you can use to debug the guest OS using the crash utility, which is somehow enhanced gdb for this purpose, IIRC, then I guess it's the MMU mapping of everything in the guest OS.
I wanted to know why in this case, is the virtual address (denoted by
vaddr) 0 for each of the loadable segments ? Will it be okay if I load the elf file taking the values of physical address (denoted by paddr) into account ?
My guess is that those are the addresses from the MMU. Each segment has it's own vaddr <-> paddr mapping.
Specifically after loading the file, can I be certain that all of my
contents will have been loaded into memory address starting from 0 ? Will the loaded contents be present in the exact location as specified (by paddr) here ?
It depends on what you mean by loading. You wouldn't be starting that binary as any other program, it's rather a dump as you would have with a coredump. Physical address is probably just the location in the guest machine, so the thing with paddr 0 would be seabios or something BIOS-related, etc.
If you want precise answers and not guesses, I would suggest the qemu mailing list or any other related list. libvirt is not the best choice here unless someone from the other communities replies here.
HTH, Martin
Thanks and Regards.
Arnab
_______________________________________________
libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
participants (2)
-
Arnabjyoti Kalita -
Martin Kletzander