qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wen Congyang
Subject: Re: [Qemu-devel] [PATCH 12/12 v12] introduce a new monitor command 'dump-guest-memory' to dump guest's memory
Date: Wed, 18 Apr 2012 17:44:36 +0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4

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?

Thanks
Wen Congyang
> 
> Regards,
> Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]