qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v8 10/20] replay: introduce info hmp/qmp command


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] [PATCH v8 10/20] replay: introduce info hmp/qmp command
Date: Fri, 21 Dec 2018 11:07:49 +0300

> From: Markus Armbruster [mailto:address@hidden
> Pavel Dovgalyuk <address@hidden> writes:
> 
> > This patch introduces 'info replay' monitor command and
> > corresponding qmp request.
> > These commands request the current record/replay mode, replay log file name,
> > and the execution step (number or recorded/replayed instructions).
> > User may use step number for replay_seek/replay_break commands and
> > for controlling the execution of replay.
> >
> > Signed-off-by: Pavel Dovgalyuk <address@hidden>
> > Acked-by: Dr. David Alan Gilbert <address@hidden>
> >
> > --
> >
> > v2:
> >  - renamed info_replay qmp into query-replay (suggested by Eric Blake)
> > v7:
> >  - added empty line (suggested by Markus Armbruster)
> > ---
> >  hmp-commands-info.hx      |   14 ++++++++++++++
> >  hmp.h                     |    1 +
> >  qapi/misc.json            |   35 +++++++++++++++++++++++++++++++++++
> >  replay/Makefile.objs      |    3 ++-
> >  replay/replay-debugging.c |   42 ++++++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 94 insertions(+), 1 deletion(-)
> >  create mode 100644 replay/replay-debugging.c
> >
> > diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> > index cbee8b9..9f2f35e 100644
> > --- a/hmp-commands-info.hx
> > +++ b/hmp-commands-info.hx
> > @@ -918,6 +918,20 @@ STEXI
> >  Show SEV information.
> >  ETEXI
> >
> > +    {
> > +        .name       = "replay",
> > +        .args_type  = "",
> > +        .params     = "",
> > +        .help       = "show parameters of the record/replay",
> > +        .cmd        = hmp_info_replay,
> > +    },
> > +
> > +STEXI
> > address@hidden info replay
> > address@hidden info replay
> > +Display the current record/replay mode and the currently executing step.
> > +ETEXI
> > +
> >  STEXI
> >  @end table
> >  ETEXI
> > diff --git a/hmp.h b/hmp.h
> > index 5f1addc..d792149 100644
> > --- a/hmp.h
> > +++ b/hmp.h
> > @@ -148,5 +148,6 @@ void hmp_hotpluggable_cpus(Monitor *mon, const QDict 
> > *qdict);
> >  void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
> >  void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
> >  void hmp_info_sev(Monitor *mon, const QDict *qdict);
> > +void hmp_info_replay(Monitor *mon, const QDict *qdict);
> >
> >  #endif
> > diff --git a/qapi/misc.json b/qapi/misc.json
> > index 8325e0d..e47aea6 100644
> > --- a/qapi/misc.json
> > +++ b/qapi/misc.json
> > @@ -3113,6 +3113,41 @@
> >    'data': [ 'none', 'record', 'play' ] }
> >
> >  ##
> > +# @ReplayInfo:
> > +#
> > +# Status of the record/replay mode.
> > +#
> > +# @mode: current mode.
> > +#
> > +# @filename: name of the record/replay log file.
> > +#
> > +# @step: current step number.
> > +#
> > +# Since: 4.0
> > +#
> > +##
> > +{ 'struct': 'ReplayInfo',
> > +  'data': { 'mode': 'ReplayMode', '*filename': 'str', 'step': 'int' } }
> 
> @filename is optional.  For each ReplayMode: is @filename always absent,
> always present, or can it be either?
> 
> > +
> > +##
> > +# @query-replay:
> > +#
> > +# Retrieves the status of the execution record/replay.
> > +#
> > +# Returns: structure with the properties of the record/replay.
> 
> You've used "parameters of the record/replay" (in HMP help info),
> "status of the record/replay mode" (QMP ReplayInfo doc), "the status of
> the execution record/replay" (QMP query-replay doc), and "structure with
> the properties of the record/replay".  Please pick one.  I think I'd
> pick "record/replay information".
> 
> In my (superficial) review of v6, I asked what a client would do with
> @step.  You gave two use cases:
> 
>  1. Control current step to be sure that replay is not stalled due to the bug.
>  2. Requesting the step for some moment of execution to use it as a parameter
>     of replay_seek/replay_break operations. I.e., for returning to the same
>     point later.
> 
> The first one is a bit vague.  The second one sounds plausible enough to
> me at least for stopped VMs (for running VMs, it feels too imprecise to
> be useful, but what do I know).  replay-break is in PATCH 11,
> replay-seek in PATCH 12.  Would it make sense add a suitable reference
> to ReplayInfo's documentation then?

Thanks for reviewing, I'll update this in the next version.

Pavel Dovgalyuk





reply via email to

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