Re: [Qemu-devel] [PATCH] tests/boot-sector: Increase timeout to 600 seconds

[Thomas Huth <thuth@redhat.com>]

On 26.09.2017 22:35, Stefan Weil wrote:
> Am 26.09.2017 um 21:30 schrieb Michael S. Tsirkin:
>> On Fri, Sep 22, 2017 at 05:06:57AM +0200, Thomas Huth wrote:
>>> If QEMU has been compiled with the flags --enable-tcg-interpreter and
>>> --enable-debug, the guest is running incredibly slow. The pxe boot test
>>> can take up to 400 seconds when testing the pseries ppc64 machine. While
>>> we should still look for ways to speed up the test on the pseries machine,
>>> it's better to increase the timeout in this test to 600 seconds anyway to
>>> allow the test to pass successfully now with this unusal configuration
>>> already.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>
>> Well I do break things sometimes and I won't be happy about
>> spending 10 minutes waiting for a test to fail.
>>
>> Can we break out of the test if all CPUs are halted with
>> interrupts disabled?

qemu-system-s390x exits automatically in that case (unless you specified
the -no-shutdown parameter) ... what about x86?

Another idea: We could run the "info registers" HMP command regularly
(is there an equivalent for HMP?) to see whether the guest is still
doing something and abort if the all registers stayed the same for,
let's say 30 seconds?

> Any fixed timeout is either too long (when you expect a failing
> test) or too short (when you need time for the test to pass).
> 
> Would it be possible to get some speed factor (like Linux
> bogomips) at the beginning of all tests? Then that factor
> could be used later for all tests which currently use a
> hard timeout.

We've got at least three changing factors here: Hardware speed of the
host (MHz / bogomips), speed of TCG / the emulated guest (e.g. TCI is
slow) and current other workload of the host. Even if we get the first
two factors right, the workload of the host can still change very
dynamically, so I think it's quite hard to do a good prediction at the
beginning of the test here.

 Thomas