Re: [Qemu-devel] dump-guest-memory enhancement.

[Laszlo Ersek]

On 11/11/13 04:28, Phi Debian wrote:

> CU82$ /usr/bin/readelf -a vmcore

> Program Headers:
>   Type     Offset      VirtAddr        PhysAddr   FileSiz    MemSiz  Flg Align
>   NOTE   0x000074 0x00000000 0x00000000 0x000a0 0x000a0     0
>   LOAD   0x000114 0x60000000 0x60000000 0x40000000 0x40000000     0

> The Align fot the PT_LOAD is ZERO, then the offset is 0x114, having an
> Align set to TARGET_PAGE_BITS, (or at least 4Kb) would provide a
> chance for any debugger to do page align copy (either lseek/read, or
> mmap) as they trip on the core, marginal detail, but may help.

I checked <http://refspecs.linuxbase.org/elf/gabi4+/ch5.pheader.html>,
and now it starts to make sense to me.

But first, I think you meant TARGET_PAGE_SIZE, not TARGET_PAGE_BITS, for
the p_align field.

So, the specs say for p_align:

> As ``Program Loading'' describes in this chapter of the processor
> supplement, loadable process segments must have congruent values for
> p_vaddr and p_offset, modulo the page size. This member gives the
> value to which the segments are aligned in memory and in the file.
> Values 0 and 1 mean no alignment is required. Otherwise, p_align
> should be a positive, integral power of 2, and p_vaddr should equal
> p_offset, modulo p_align.

In one sentence, p_vaddr and p_offset should produce the same remainder
when divided by p_align. I guess you could implement this by adding some
buffer space between the headers and the "meat" of the file.

IMHO this requirement isn't necessarily a hard one for vmcores, as we're
not trying to map-and-execute these segments.

> As an example, a userland main(){abort();} kind of prog would produce
> a core file like this.
> 
> CM01$ readelf -a core.2000
> ...
>     LOAD off    0x0000000000001000 vaddr 0x0000000000400000 paddr
> 0x0000000000000000 align 2**12
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   NOTE           0x0001d4 0x00000000 0x00000000 0x001d8 0x00000     0
>   LOAD           0x001000 0x00a42000 0x00000000 0x00000 0x1b000 R E 0x1000
>   LOAD           0x002000 0x00a5e000 0x00000000 0x01000 0x01000 RW  0x1000
> 
> The align for LOAD's is 0x1000 thus the file offset is 0x01000, 0x2000 etc...

Understood. Seems to be consistent with the above.

> I guess dump-guest-memory is of a marginal use,

Strongly disagree :)

> yet it can be usefull
> when kexec/kdump is broken or non existant on some new architecture
> (os/arch bring up).

It's also important when you want to control the dumping process from
the host side (including the location of the vmcore). You might want to
grab a dump without a guest kernel panic too.

> So to answer your question, the content of the PT_LOAD is ok, only its
> offset is non aligned.

I actually meant the question the other way around. Apparently, the
offset of the PT_LOAD entry itself (ie. where it is in the file) is OK;
its contents could be improved perhaps (the p_offset and p_align fields).

> I got to precise I obtained this vmcore by implementing the arc_arm
> part of the qemu dump-guest-memory, and planing to do the same for
> arm64, I may have mis-used the QEMU API's, but for what I can read,
> the align member is left non initialised after a memset(zero) of the
> phdr/shdr i.e it is left at zero, and I got the impression that the
> wayt the elf is produced, section/progs alignment was not in mind.

I haven't been there at the original creation of this functionality, but
I tend to agree with you. For analyzing the vmcore with gdb or crash,
the alignment doesn't seem to be important, so it was probably ignored.

> So
> I guess other arch are not aligned either, I did not test that.

It seems to be so, yes.

I think that implementing the arch-specific bits (currently: stubs) for
a new architectire, for dump-guest-memory, would be very useful.

OTOH reworking the generic dump code for the alignment (non-)issue seems
to be more risk than worth to me, unless the produced vmcore is actually
unusable on a specific platform. I'm not opposing or trying to block it
of course, it's just plain ol' "don't fix it if it ain't broken" and
"keep the complexity down" for me.

If I understand correctly, the benefit of getting the alignment
pedantically right would be "a chance for any debugger to do page align
copy (either lseek/read, or mmap)". Is that right?

I can't imagine it would be noticeable in performance on x86_64 with
crash or gdb. Is the performance significantly different on ARM?

Thanks
Laszlo