| Message ID | 201205042123.q44LNp9x029061@int-mx01.intmail.prod.int.phx2.redhat.com |
|---|---|
| State | New |
| Headers | show |
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 <jbaron@redhat.com> > --- > 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? 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 also be an option that allows the guest to be dumped on a segfault, now separately? Thanks, -Jason
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 <jbaron@redhat.com> > > --- > > 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 > also be an option that allows the guest to be dumped on a segfault, now > separately? Isnt what this option does? (well, disabling it).
Marcelo Tosatti <mtosatti@redhat.com> 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 <jbaron@redhat.com> >> > --- >> > 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.
On Thu, Jul 05, 2012 at 09:04:18PM -0300, Marcelo Tosatti wrote: > 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 <jbaron@redhat.com> > > > --- > > > 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 > > also be an option that allows the guest to be dumped on a segfault, now > > separately? > > Isnt what this option does? (well, disabling it). > Right, disabling it gives us both qemu and guest bits. So I was just suggesting a mode that dumps guest bits but not qemu bits. (Probably that is setup in guest, though). So I'm not sure if that makes sense. But as Markus suggested, if we make the interface more general, we are more open to something like that later (at least in terms of the interface). Thanks, -Jason
On 07/06/2012 08:11 AM, Markus Armbruster wrote: > > 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. -m 2T,dump=no ?
diff --git a/exec.c b/exec.c index 0607c9b..f9d2b93 100644 --- a/exec.c +++ b/exec.c @@ -35,6 +35,7 @@ #include "qemu-timer.h" #include "memory.h" #include "exec-memory.h" +#include "sysemu.h" #if defined(CONFIG_USER_ONLY) #include <qemu.h> #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) @@ -2605,6 +2606,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, MemoryRegion *mr) { RAMBlock *new_block; + int ret; size = TARGET_PAGE_ALIGN(size); new_block = g_malloc0(sizeof(*new_block)); @@ -2659,6 +2661,17 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS), 0xff, size >> TARGET_PAGE_BITS); + + /* Use MADV_DONTDUMP, if user doesn't want the guest memory in the core */ + if (dont_dump_guest) { + ret = qemu_madvise(new_block->host, size, QEMU_MADV_DONTDUMP); + if (ret) { + perror("qemu_madvise"); + fprintf(stderr, "madvise doesn't support MADV_DONTDUMP, " + "but -dont-dump-guest-core specified\n"); + } + } + if (kvm_enabled()) kvm_setup_guest_memory(new_block->host, size); diff --git a/osdep.h b/osdep.h index 9db8766..db275f2 100644 --- a/osdep.h +++ b/osdep.h @@ -100,6 +100,11 @@ void qemu_vfree(void *ptr); #else #define QEMU_MADV_MERGEABLE QEMU_MADV_INVALID #endif +#ifdef MADV_DONTDUMP +#define QEMU_MADV_DONTDUMP MADV_DONTDUMP +#else +#define QEMU_MADV_DONTDUMP QEMU_MADV_INVALID +#endif #elif defined(CONFIG_POSIX_MADVISE) @@ -107,6 +112,7 @@ void qemu_vfree(void *ptr); #define QEMU_MADV_DONTNEED POSIX_MADV_DONTNEED #define QEMU_MADV_DONTFORK QEMU_MADV_INVALID #define QEMU_MADV_MERGEABLE QEMU_MADV_INVALID +#define QEMU_MADV_DONTDUMP QEMU_MADV_INVALID #else /* no-op */ @@ -114,6 +120,7 @@ void qemu_vfree(void *ptr); #define QEMU_MADV_DONTNEED QEMU_MADV_INVALID #define QEMU_MADV_DONTFORK QEMU_MADV_INVALID #define QEMU_MADV_MERGEABLE QEMU_MADV_INVALID +#define QEMU_MADV_DONTDUMP QEMU_MADV_INVALID #endif diff --git a/qemu-options.hx b/qemu-options.hx index a169792..ae12cc6 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2724,6 +2724,11 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "-qtest-log LOG specify tracing options\n", QEMU_ARCH_ALL) +DEF("dont-dump-guest", 0, QEMU_OPTION_dont_dump_guest, + "-dont-dump-guest\n" + " do not dump guest core\n", + QEMU_ARCH_ALL) + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table diff --git a/sysemu.h b/sysemu.h index bc2c788..f738f34 100644 --- a/sysemu.h +++ b/sysemu.h @@ -131,6 +131,7 @@ extern uint8_t *boot_splash_filedata; extern int boot_splash_filedata_size; extern uint8_t qemu_extra_params_fw[2]; extern QEMUClock *rtc_clock; +extern int dont_dump_guest; #define MAX_NODES 64 extern int nb_numa_nodes; diff --git a/vl.c b/vl.c index ae91a8a..6259c21 100644 --- a/vl.c +++ b/vl.c @@ -232,6 +232,7 @@ int boot_menu; uint8_t *boot_splash_filedata; int boot_splash_filedata_size; uint8_t qemu_extra_params_fw[2]; +int dont_dump_guest; typedef struct FWBootEntry FWBootEntry; @@ -3191,6 +3192,9 @@ int main(int argc, char **argv, char **envp) case QEMU_OPTION_qtest_log: qtest_log = optarg; break; + case QEMU_OPTION_dont_dump_guest: + dont_dump_guest = 1; + break; default: os_parse_cmd_args(popt->index, optarg); }
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 <jbaron@redhat.com> --- exec.c | 13 +++++++++++++ osdep.h | 7 +++++++ qemu-options.hx | 5 +++++ sysemu.h | 1 + vl.c | 4 ++++ 5 files changed, 30 insertions(+), 0 deletions(-)