Re: [Qemu-devel] dump-guest-memory enhancement.
Hi Laszlo, On Mon, Nov 11, 2013 at 8:38 PM, Laszlo Ersek ler...@redhat.com 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
[Qemu-devel] dump-guest-memory enhancement.
Hi All, I implemented guest-dump-memory for arm32, and bumped in something strange, the PT_LOADs generated from dump.c are not target page aligned. There are some advantage to get PT_LOAD aligned. This mail is to ask advise about patch I could submit later if wanted. Would it be desirable to get the PT_LOAD aligned on target page size always, for all arch ? If so I could fix dump.c, but may be people using dump-guest-memory on existing current implementation may object, dunno if some of there tools (debuggers) are dependent of the non aligned current setup (gdb would nt complain) If not wanted for existing arch (s390, ppc, i386), may be I could do it for arm only. Or ultimatly may be this is not wanted at all, in this case I keep my dumper for myself :) Cheers, Phi
Re: [Qemu-devel] dump-guest-memory enhancement.
Hi All,
Sorry Laszlo for flooding your mailbox, I missed the 'reply to all' so
I redo the post here.
And I added some more comment at the end to answer your questions.
Phi
==
CU82$ /usr/bin/readelf -a vmcore
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddrPhysAddr FileSizMemSiz Flg Align
NOTE 0x74 0x 0x 0x000a0 0x000a0 0
LOAD 0x000114 0x6000 0x6000 0x4000 0x4000 0
There is no dynamic section in this file.
There are no relocations in this file.
No version information found in this file.
Notes at offset 0x0074 with length 0x00a0:
Owner Data size Description
CORE 0x008c NT_PRSTATUS (prstatus structure)
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.
As an example, a userland main(){abort();} kind of prog would produce
a core file like this.
CM01$ readelf -a core.2000
...
LOAD off0x1000 vaddr 0x0040 paddr
0x align 2**12
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x0001d4 0x 0x 0x001d8 0x0 0
LOAD 0x001000 0x00a42000 0x 0x0 0x1b000 R E 0x1000
LOAD 0x002000 0x00a5e000 0x 0x01000 0x01000 RW 0x1000
The align for LOAD's is 0x1000 thus the file offset is 0x01000, 0x2000 etc...
==
I guess dump-guest-memory is of a marginal use, yet it can be usefull
when kexec/kdump is broken or non existant on some new architecture
(os/arch bring up).
So to answer your question, the content of the PT_LOAD is ok, only its
offset is non aligned.
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. So
I guess other arch are not aligned either, I did not test that.
Cheers,
Phi
[Qemu-devel] TARGET_AARCH64
Hi All, Browsing the qemu 'latest' src, I see some #define TARGET_AARCH64, does it mean we can boot a qemu-system-arm64 ? Is there some experiment? Cheers, Phi
Re: [Qemu-devel] TARGET_AARCH64
Exciting. Thanx Peter.
[Qemu-devel] How to paginate QEMU monitor display
Hi All, I got a qemu-system-arm running, doing alt3 I got a monitor in a X11 window (doens't sound s like an xterm), I can issue there an (qemu) info tree I need to see it all, yet I can only see the end of it I can't scroll back and look at the begining. Am I doing something wrong? (I did try a brute | or nothing works) Cheers Phi
Re: [Qemu-devel] How to paginate QEMU monitor display
Oops forget this, I discovered -monitor :) Cheers, Phi
[Qemu-devel] guest-dump-memory
Hi All, I tried to subscribe to this list, but never got teh confirm mail. So I write here non subscribed, so add my email addr in replies. I am trying to use guest-dump-memory on arm (arm32, armv7* name it) with qemu 1.6.1. The command is 'implemented' i.e listed in the help, but it create an empty file and a replis saying dump-gues-memory is not implemented. The logs says that ARM implement dump-guest-memory since 1.2 http://wiki.qemu.org/ChangeLog/1.2 Is it working ? or did I missed a configuration option? Thanx for any helps. Cheers, Phi
