Re: [Qemu-devel] [PATCH 12/12 v12] introduce a new monitor command 'dump-guest-memory' to dump guest's memory

[Daniel P. Berrange]

On Wed, Apr 18, 2012 at 05:44:36PM +0800, Wen Congyang wrote:
> At 04/18/2012 05:23 PM, Daniel P. Berrange Wrote:
> > 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.
> 
> Here is the libvirt's code in doCoreDump():
> 
>     /* Core dumps usually imply last-ditch analysis efforts are
>      * desired, so we intentionally do not unlink even if a file was
>      * created.  */
>     if ((fd = qemuOpenFile(driver, path,
>                            O_CREAT | O_TRUNC | O_WRONLY | directFlag,
>                            NULL, NULL)) < 0)
> 
> 
> In my test, the fd returns from qemuOpenFile is not a pipe FD. So
> O_DIRECT still exists.
> Do I miss something?

If we turned on O_DIRECT on the 'fd' that we pass to QEMU, then QEMU
needs to be carefully written to use aligned memory buffers and do
writes in the correct size. It almost certainly does not do this
correctly.

Thus libvirt uses a I/O helper process where the I/O helper has the
FD for the actual file and QEMU just gets a pipe FD. Thus only the
I/O helper needs to careful about O_DIRECT alignment issues.


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