[PATCH] conf: Add qemu_job_wait_time option

Michal Privoznik mprivozn at redhat.com
Mon May 4 08:13:26 UTC 2020


On 5/4/20 10:07 AM, Peter Krempa wrote:
> On Fri, May 01, 2020 at 16:09:04 +0900, MIKI Nobuhiro wrote:
>> The waiting time to acquire the lock times out, which leads to a segment fault.
> 
> Could you please elaborate here? Adding this band-aid is pointless if it
> can timeout later. We do want to fix any locking issue but without
> information we can't really.
> 
>> In essence we should make improvements around locks, but as a workaround we
>> will change the timeout to allow the user to increase it.
>> This value was defined as 30 seconds, so use it as the default value.
>> The logs are as follows:
>>
>> ```
>> Timed out during operation: cannot acquire state change lock \
>>     (held by monitor=remoteDispatchDomainCreateWithFlags)
>> libvirtd.service: main process exited, code=killed,status=11/SEGV
>> ```
> 
> Unfortunately I don't consider this a proper justification for the
> change below. Either re-state why you want this, e.g. saying that
> shortening time may give users greater feedback, but mentioning that it
> works around a crash is not acceptable as a justification for something
> which doesn't fix the crash.

Agreed. Allowing users to configure the timeout makes sense - we already 
do that for other timeouts, but if it is masking a real bug we need to 
fix it first. Do you have any steps to reproduce the bug? Are you able 
to get the stack trace from the coredump?

> 
>> Signed-off-by: MIKI Nobuhiro <nmiki at yahoo-corp.jp>
>> ---
>>   docs/news.xml                      | 9 +++++++++
>>   src/qemu/libvirtd_qemu.aug         | 1 +
>>   src/qemu/qemu.conf                 | 3 +++
>>   src/qemu/qemu_conf.c               | 3 +++
>>   src/qemu/qemu_conf.h               | 2 ++
>>   src/qemu/qemu_domain.c             | 7 ++-----
>>   src/qemu/test_libvirtd_qemu.aug.in | 1 +
>>   7 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/docs/news.xml b/docs/news.xml
>> index 80819ae..3755c49 100644
>> --- a/docs/news.xml
>> +++ b/docs/news.xml
>> @@ -119,6 +119,15 @@
>>             Bounds Checking) and IBS (Indirect Branch Speculation).
>>           </description>
>>         </change>
>> +      <change>
>> +        <summary>
>> +          conf: Add job wait time setting to qemu.conf
>> +        </summary>
>> +        <description>
>> +          How many seconds the new job waits for the existing job to finish.
>> +          This only affects if you are using qemu as driver.
>> +        </description>
>> +      </change>
>>       </section>
>>       <section title="Improvements">
>>       </section>
> 
> Changes to news.xml always must be in a separate commit.

Just a short explanation - this is to ease possible backports. For 
instance, if there is a bug fix in version X, but a distro wants to 
backport it to version X-1 then the news.xml looks completely different 
there and the cherry-pick won't apply cleanly.

> 
>> diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
>> index 404498b..76c896e 100644
>> --- a/src/qemu/libvirtd_qemu.aug
>> +++ b/src/qemu/libvirtd_qemu.aug
>> @@ -97,6 +97,7 @@ module Libvirtd_qemu =
>>                    | bool_entry "dump_guest_core"
>>                    | str_entry "stdio_handler"
>>                    | int_entry "max_threads_per_process"
>> +                 | int_entry "qemu_job_wait_time"
>>   
>>      let device_entry = bool_entry "mac_filter"
>>                    | bool_entry "relaxed_acs_check"
>> diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
>> index abdbf07..a05aaa5 100644
>> --- a/src/qemu/qemu.conf
>> +++ b/src/qemu/qemu.conf
>> @@ -612,6 +612,9 @@
>>   #
>>   #max_threads_per_process = 0
>>   
>> +# How many seconds the new job waits for the existing job to finish.
>> +#qemu_job_wait_time = 30
>> +
>>   # If max_core is set to a non-zero integer, then QEMU will be
>>   # permitted to create core dumps when it crashes, provided its
>>   # RAM size is smaller than the limit set.
> 
> Rest of the patch looks good code-wise.
> 

Yes.

Michal




More information about the libvir-list mailing list