[libvirt-users] Understanding the contents of virsh dump --memory-only

[Arnabjyoti Kalita]

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 at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvirt-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170802/5d3020ce/attachment.htm>