qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] memory: add -dont-dump-guest option to reduce c


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] memory: add -dont-dump-guest option to reduce core dump size
Date: Fri, 06 Jul 2012 07:11:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Marcelo Tosatti <address@hidden> writes:

> On Mon, May 21, 2012 at 01:53:36PM -0400, Jason Baron wrote:
>> On Fri, May 04, 2012 at 05:23:51PM -0400, Jason Baron wrote:
>> > Add a command line parameter to not dump guest memory in the core dump, the
>> > command line is: -dont-dump-guest. This brought the core dump down from
>> > 383MB to 13 MB on a 1GB guest.
>> > 
>> > Signed-off-by: Jason Baron <address@hidden>
>> > ---
>> >  exec.c          |   13 +++++++++++++
>> >  osdep.h         |    7 +++++++
>> >  qemu-options.hx |    5 +++++
>> >  sysemu.h        |    1 +
>> >  vl.c            |    4 ++++
>> >  5 files changed, 30 insertions(+), 0 deletions(-)
>> > 
>> 
>> Any thoughts on this? Is the guest memory often helpful in debugging
>> when the qemu process segfaults?
>
> For most development related usage, no (with large guests, its 
> troublesome).
>
> Please add documentation for the command (patch looks fine otherwise).
>
>> This feature also seems useful if somebody is running a sensitive
>> workload, such that the non-sensitive qemu state can be dumped
>> independently of the guest state. In that case, perhaps there should

I wouldn't make claims related to guest data confidentiality, because
sensitive stuff could conceivably leak from guest RAM (not dumped) into
device model state (dumped).

>> also be an option that allows the guest to be dumped on a segfault, now
>> separately?
>
> Isnt what this option does? (well, disabling it).

It seems there could be more knobs to control than just "dump guest
state yes/no".  Therefore, extensible command line syntax like
"--core-dump guest-ram=off" seems to be advisable.  We have too many
-dont-do-FOO options already.



reply via email to

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