d43a01db | 18-Sep-2023 |
Stephen Brennan <stephen.s.brennan@oracle.com> |
dump: Allow directly outputting raw kdump format
The flattened format (currently output by QEMU) is used by makedumpfile only when it is outputting a vmcore to a file which is not seekable. The flat
dump: Allow directly outputting raw kdump format
The flattened format (currently output by QEMU) is used by makedumpfile only when it is outputting a vmcore to a file which is not seekable. The flattened format functions essentially as a set of instructions of the form "seek to the given offset, then write the given bytes out".
The flattened format can be reconstructed using makedumpfile -R, or makedumpfile-R.pl, but it is a slow process because it requires copying the entire vmcore. The flattened format can also be directly read by crash, but still, it requires a lengthy reassembly phase.
To sum up, the flattened format is not an ideal one: it should only be used on files which are actually not seekable. This is the exact strategy which makedumpfile uses, as seen in the implementation of "write_buffer()" in makedumpfile [1]. However, QEMU has always used the flattened format. For compatibility it is best not to change the default output format without warning. So, add a flag to DumpState which changes the output to use the normal (i.e. raw) format. This flag will be added to the QMP and HMP commands in the next change.
[1]: https://github.com/makedumpfile/makedumpfile/blob/f23bb943568188a2746dbf9b6692668f5a2ac3b6/makedumpfile.c#L5008-L5040
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [ Marc-André: replace loff_t with off_t ] Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20230918233233.1431858-3-stephen.s.brennan@oracle.com>
show more ...
|
433fcea4 | 13-Sep-2023 |
Stefan Hajnoczi <stefanha@redhat.com> |
util/defer-call: move defer_call() to util/
The networking subsystem may wish to use defer_call(), so move the code to util/ where it can be reused.
As a reminder of what defer_call() does:
This A
util/defer-call: move defer_call() to util/
The networking subsystem may wish to use defer_call(), so move the code to util/ where it can be reused.
As a reminder of what defer_call() does:
This API defers a function call within a defer_call_begin()/defer_call_end() section, allowing multiple calls to batch up. This is a performance optimization that is used in the block layer to submit several I/O requests at once instead of individually:
defer_call_begin(); <-- start of section ... defer_call(my_func, my_obj); <-- deferred my_func(my_obj) call defer_call(my_func, my_obj); <-- another defer_call(my_func, my_obj); <-- another ... defer_call_end(); <-- end of section, my_func(my_obj) is called once
Suggested-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230913200045.1024233-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
5d9ec1f4 | 17-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
kvm: assume that many ioeventfds can be created
NR_IOBUS_DEVS was increased to 200 in Linux 2.6.34. By Linux 3.5 it had increased to 1000 and later ioeventfds were changed to not count against the
kvm: assume that many ioeventfds can be created
NR_IOBUS_DEVS was increased to 200 in Linux 2.6.34. By Linux 3.5 it had increased to 1000 and later ioeventfds were changed to not count against the limit. But the earlier limit of 200 would already be enough for kvm_check_many_ioeventfds() to be true, so remove the check.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
f8c0687f | 21-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
kvm: require KVM_IRQFD for kernel irqchip
KVM_IRQFD was introduced in Linux 2.6.32, and since then it has always been available on architectures that support an in-kernel interrupt controller. We ca
kvm: require KVM_IRQFD for kernel irqchip
KVM_IRQFD was introduced in Linux 2.6.32, and since then it has always been available on architectures that support an in-kernel interrupt controller. We can require it unconditionally.
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
a788260b | 17-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
kvm: require KVM_IRQFD for kernel irqchip
KVM_IRQFD was introduced in Linux 2.6.32, and since then it has always been available on architectures that support an in-kernel interrupt controller. We ca
kvm: require KVM_IRQFD for kernel irqchip
KVM_IRQFD was introduced in Linux 2.6.32, and since then it has always been available on architectures that support an in-kernel interrupt controller. We can require it unconditionally.
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
66bbe3e9 | 03-Oct-2023 |
Clément Chigot <chigot@adacore.com> |
softmmu: pass the main loop status to gdb "Wxx" packet
gdb_exit function aims to close gdb sessions and sends the exit code of the current execution. It's being called by qemu_cleanup once the main
softmmu: pass the main loop status to gdb "Wxx" packet
gdb_exit function aims to close gdb sessions and sends the exit code of the current execution. It's being called by qemu_cleanup once the main loop is over. Until now, the exit code sent was always 0. Now that hardware can shutdown this main loop with custom exit codes, these codes must be transfered to gdb as well.
Signed-off-by: Clément Chigot <chigot@adacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231003071427.188697-3-chigot@adacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|