On 11/4/2020 4:40 PM, Alex Bennée wrote:
> Eric Blake <ebl...@redhat.com> writes:
>> 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? Can we get by with
>> ONLY a command line option?
>>
>> Also, how does this option differ from what we already have with qemu
>> --preconfig?
>
> In the original discussion:
>
> Subject: [PATCH V1 12/32] vl: pause option
> Date: Thu, 30 Jul 2020 08:14:16 -0700
> Message-Id: <1596122076-341293-13-git-send-email-steven.sist...@oracle.com>
>
> it seems the idea was to stop qemu as early as possible for debugging
> when launched by some other launcher which wasn't modifiable except by
> pass through configuration to QEMU's command line.
>
> <snip>
>
>> 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?
>
> I agree - this feels like a bit of an over complication as a debug
> helper. How many times can a failure to launch by some binary blob not
> be debugged by either a gdb follow-fork or a copying of the command line
> and running gdb --args?
Follow fork is awkward and error prone when the launcher performs many forks
before forking
qemu. gdb --args does not work when the launcher sets up an environment for
qemu to run
in, pre-opening fd's being just one example. For developers, often the
"launcher" is a
script that performs setup and passes the myriad qemu options. Even in that
case, it is
easier to add a flag or set an env var to enable debugging. The pause option is
fast
(for the user) and reliable.
I have a new version of the patch that handles the signal more smoothly, so the
handshake
with gdb is easier:
$ QEMU_PAUSE=1 qemu-system-x86_64 ...
QEMU pid 18371 is stopped.
$ gdb -p 18371
(gdb) break rcu_init
(gdb) signal SIGCONT
Breakpoint 1, rcu_init () at util/rcu.c:380
The implementation does not even send a signal to qemu, so the launcher is none
the wiser:
static void pause_me(void)
{
int sig;
sigset_t set, oldset;
sigemptyset(&set);
sigaddset(&set, SIGCONT);
printf("QEMU pid %d is stopped. Send SIGCONT to continue.\n", getpid());
sigprocmask(SIG_BLOCK, &set, &oldset);
sigwait(&set, &sig); <-- PAUSES HERE
sigprocmask(SIG_SETMASK, &oldset, 0);
}
I will post it if you are still open to the idea. Please let me know.
- Steve
