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

[Phi Debian]

Hi Laszlo,


On Mon, Nov 11, 2013 at 8:38 PM, Laszlo Ersek <address@hidden> wrote:

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

I said TARGET_PAGE_BITS, because as you noticed in your spec text,
p_align is a power of 2, if you want a 4096 byte aligned section (or
prog header) you would stick 12 in there, i.e the number of bits.

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

Not map-and-execute, but map-and-read sure enough :)



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

Yes, when fixing code you may simply break it :)

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

yes.

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

When number of crashdump pages to bring in start to be 'big'  having
it non aligned double the number of page faults, if the panic dump
path would generate non aligned gigantic dump I would voice a bit more
:)

For qemu, we can safely ignore all this, as cross-arch qemu is mainly
for bring up, and then I guess it will never run gigantic models, so
never dump gigantic dump.

You right, qemu dump-guest-memory is much more than a 'dump on panic'
is more like get a 'live-dump' you can snapshot at different point of
time in your OS load.

So in conclusion we stay the way it is, the ELF is semantically
correct and debuggers can deal with it.

Thanx for taking time to look at it.

Cheers
Phi