Re: [PATCH V2] vl: pause option

[Steven Sistare <steven.sistare@oracle.com>]

On 11/4/2020 2:26 PM, Eric Blake wrote:
> On 11/2/20 9:50 AM, Steve Sistare wrote:
>> Provide the -pause command-line parameter and the QEMU_PAUSE environment
>> variable to pause QEMU during process startup using SIGSTOP and allow a
>> developer to attach a debugger, or observe the process using tools such as
>> strace.  Useful when the QEMU has been launched with some other entity, such
>> as libvirt.  QEMU_PAUSE is checked in a constructor at the highest priority,
>> and can be used to debug other constructors.  The -pause option is checked
>> later, during argument processing in main, but is useful if passing an
>> environment variable from a launcher to qemu is awkard.
>>
>> Usage: qemu -pause, or QEMU_PAUSE=1
>> After attaching a debugger, send SIGCONT to the qemu process to continue.
> 
> Changing behavior via a new environment variable is awkward.  What
> happens, for example, if libvirt inherits this variable set, but is not
> aware of its impact to alter how qemu starts up? 

The env var is intended to only be set by a developer.  The developer is responsible
for sending SIGCONT, not libvirt.  libvirt does not need to understand the semantics
of QEMU_PAUSE.

For libvirt, the developer would add this to the domain definition file, so it only
applies to that domain:

<qemu:commandline>
   <qemu:env name='QEMU_PAUSE' value='1'/>
</qemu:commandline>

>  Can we get by with ONLY a command line option?

The command line option is sufficient most of the time and I would be happy to get
at least that.  The env var is even better, and if I do not push it, someone else
will!

> Also, how does this option differ from what we already have with qemu
> --preconfig?

pause stops the qemu process earlier, so more can be debugged before it occurs.
With preconfig, qemu is still running its event loop and may respond to external
events such as monitor requests, which may be undesirable.

- Steve

>> Example:
>>
>> $ QEMU_PAUSE=1 qemu-system-x86_64 ...
>> QEMU pid 18371 is stopped.
>> [1]+  Stopped
>>                                  $ gdb -p 18371
>>                                  (gdb)
>> $ kill -cont 18371
>>                                  (gdb) break rcu_init
>>                                  (gdb) continue
>>                                  Program received signal SIGCONT, Continued.
>>                                  (gdb) continue
>>                                  Breakpoint 1, rcu_init () at util/rcu.c:380
>>
>> Thanks to Daniel P. Berrange <berrange@redhat.com> for suggesting SIGSTOP.
>>
>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
>> ---
>>  qemu-options.hx | 14 ++++++++++++++
>>  softmmu/vl.c    | 23 +++++++++++++++++++++++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 708583b..42edd70 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -3668,6 +3668,20 @@ SRST
>>      option is experimental.
>>  ERST
>>  
>> +DEF("pause", 0, QEMU_OPTION_pause, \
>> +    "-pause          pause the qemu process in main using SIGSTOP.\n"
>> +    "                to pause earlier, before constructors are run, set the\n"
>> +    "                environment variable QEMU_PAUSE=1 before starting qemu.\n",
>> +    QEMU_ARCH_ALL)
>> +
>> +SRST
>> +``-pause``
>> +    Pause the qemu process in main using SIGSTOP.  This is useful for attaching
>> +    a debugger after QEMU has been launched by some other entity.  After
>> +    attaching, send SIGCONT to continue.  To pause earlier, before constructors
>> +    are run, set the environment variable QEMU_PAUSE=1 before starting qemu.
>> +ERST
> 
> Isn't it always possible to provide a wrapper qemu process to be invoked
> by whatever third-party management app (like libvirt), where your
> wrapper then starts the real qemu under gdb to begin with, rather than
> having to hack qemu itself to have a special start-up mode?
>