libvirt users - Aug 2017 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20170801/f85891ae/attachment.htm>

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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20170802/6d5a5f93/attachment.sig>

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