Age | Commit message (Collapse) | Author | Files | Lines |
|
RAMBlock.offset --> GuestPhysBlock.target_start
RAMBlock.offset + RAMBlock.length --> GuestPhysBlock.target_end
RAMBlock.length --> GuestPhysBlock.target_end -
GuestPhysBlock.target_start
"GuestPhysBlock.host_addr" is only used when writing the dump contents.
This patch enables "crash" to work with the vmcore by rebasing the vmcore
from the left side of the following diagram to the right side:
host-private
offset
relative
to ram_addr RAMBlock guest-visible paddrs
0 +-------------------+.....+-------------------+ 0
| ^ | | ^ |
| 640 KB | | 640 KB |
| v | | v |
0x0000a0000 +-------------------+.....+-------------------+ 0x0000a0000
| ^ | |XXXXXXXXXXXXXXXXXXX|
| 384 KB | |XXXXXXXXXXXXXXXXXXX|
| v | |XXXXXXXXXXXXXXXXXXX|
0x000100000 +-------------------+.....+-------------------+ 0x000100000
| ^ | | ^ |
| 3583 MB | | 3583 MB |
| v | | v |
0x0e0000000 +-------------------+.....+-------------------+ 0x0e0000000
| ^ |. |XXXXXXXXXXXXXXXXXXX|
| above_4g_mem_size | . |XXXX PCI hole XXXXX|
| v | . |XXXX XXXXX|
ram_size +-------------------+ . |XXXX 512 MB XXXXX|
. .|XXXXXXXXXXXXXXXXXXX|
. +-------------------+ 0x100000000
. | ^ |
. | above_4g_mem_size |
.| v |
+-------------------+ ram_size
+ 512 MB
Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
While the machine is paused, in guest_phys_blocks_append() we register a
one-shot MemoryListener, solely for the initial collection of the valid
guest-physical memory ranges that happens at listener registration time.
For each range that is reported to guest_phys_blocks_region_add(), we
attempt to merge the range with the preceding one.
Ranges can only be joined if they are contiguous in both guest-physical
address space, and contiguous in host virtual address space.
The "maximal" ranges that remain in the end constitute the guest-physical
memory map that the dump will be based on.
Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
The vmcore must use physical addresses that are visible to the guest, not
addresses that point into linear RAMBlocks. As first step, introduce the
list type into which we'll collect the physical mappings in effect at the
time of the dump.
Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Even a trusted & clean-state guest can map more memory than what it was
given. Since the vmcore contains RAMBlocks, mapping sizes should be
clamped to RAMBlock sizes. Otherwise such oversized mappings can exceed
the entire file size, and ELF parsers might refuse even the valid portion
of the PT_LOAD entry.
Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|
|
Move next_cpu from CPU_COMMON to CPUState.
Move first_cpu variable to qom/cpu.h.
gdbstub needs to use CPUState::env_ptr for now.
cpu_copy() no longer needs to save and restore cpu_next.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
[AF: Rebased, simplified cpu_copy()]
Signed-off-by: Andreas Färber <afaerber@suse.de>
|
|
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Acked-by: Kevin Wolf <kwolf@redhat.com>
|
|
Pass any Error out into dump_init() and have it actually stop on errors.
Whether it is unsupported on a certain CPU can be checked by looking for
a NULL CPUClass::get_memory_mapping field.
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
[AF: Reverted changes to CPU loops]
Signed-off-by: Andreas Färber <afaerber@suse.de>
|
|
Instead of calling cpu_synchronize_state() for each CPU, call the
existing cpu_synchronize_all_states() helper.
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
|
|
Convert cpu_write_elfXX_note() functions to CPUClass methods and pass
CPUState as argument. Update target-i386 accordingly.
Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
[AF: Retain stubs as CPUClass' default method implementation; style changes]
Signed-off-by: Andreas Färber <afaerber@suse.de>
|
|
Headers in include/exec/ are for the deepest innards of QEMU,
they should almost never be included directly.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Change gdbstub's cpu_index() argument to CPUState now that CPUArchState
is no longer used.
Signed-off-by: Andreas Färber <afaerber@suse.de>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific). Replace it with a finger-friendly,
standards conformant hwaddr.
Outstanding patchsets can be fixed up with the command
git rebase -i --exec 'find -name "*.[ch]"
| xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
fd_write_vmcore() will indefinitely spin for a non-blocking
file-descriptor that would block. However, if the fd is non-blocking,
how does it make sense to spin?
Change this behavior to return an error instead.
Note that this can only happen with an fd provided by a management
application. The fd opened internally by dump-guest-memory is blocking.
While there, also fix 'writen_size' variable name.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
|
|
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
|
|
dump.c was recently added to the code. It unconditionally
includes sys/procfs which is not available with MinGW (w32, w64).
It looks like this file is not needed at all (tested on Linux),
so I removed it completely.
Some other include statements are also redundant because they are
already included in qemu-common, therefore they were removed, too.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
|
|
This simplifies things, because they will only be included for softmmu
targets and because the stubs are taken out-of-line in separate files,
which in the future could even be compiled only once.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
So that it can use the same prototype in both cases.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The command's usage:
dump-guest-memory [-p] protocol [begin] [length]
The supported protocol can be file or fd:
1. file: the protocol starts with "file:", and the following string is
the file's path.
2. fd: the protocol starts with "fd:", and the following string is the
fd's name.
Note:
1. If you want to use gdb to process the core, please specify -p option.
The reason why the -p option is not default is:
a. guest machine in a catastrophic state can have corrupted memory,
which we cannot trust.
b. The guest machine can be in read-mode even if paging is enabled.
For example: the guest machine uses ACPI to sleep, and ACPI sleep
state goes in real-mode.
2. If you don't want to dump all guest's memory, please specify the start
physical address and the length.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
|