On Wed, Apr 18, 2012 at 03:30:04PM +0800, Wen Congyang wrote: > The command's usage: > dump [-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.
What is the behaviour of this command if we set '-p', and the guest is corrupt ? If '-p' is not safe when the guest is in a corrupted state, then I'd argue that '-p' is not safe *ever*, since a malicious guest could setup bad page maps at any time it likes and we've no way of knowing this from the host. > 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. This command doesn't support the fd that is is associated with a pipe, > socket, or FIFO(lseek will fail with such fd). How hard would it be to lift that restriction ? When libvirt does save to file, or core dump these days, we tend to pass a pipe FD to QEMU, which is connected to libvirt's I/O helper process. The reason for this is that it lets us turn on O_DIRECT for the dumped data, which has proved to be quite an important feature for oVirt. So I'd rather like to keep that ability with the new dump command. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
