Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

[Michael S. Tsirkin]

On Tue, Jul 11, 2017 at 04:43:50PM -0700, Ben Warren wrote:
> Hi Laszlo,
> 
> 
>     On Jul 11, 2017, at 3:13 PM, Laszlo Ersek <address@hidden> wrote:
> 
>     On 07/11/17 22:42, Peter Maydell wrote:
> 
>         On 11 July 2017 at 20:10, Michael S. Tsirkin <address@hidden> wrote:
> 
>             On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote:
> 
>                 The good news is it's not aarch64-specific. I just hit this on
>                 a build on x86_64 host, gcc, debug build:
> 
>                  GTESTER check-qtest-x86_64
>                 **
>                 ERROR:/home/petmay01/linaro/qemu-for-merges/tests/
>                 vmgenid-test.c:65:acpi_find_vgia:
>                 assertion failed (ACPI_ASSERT_CMP_str == "RSDT"): ("" ==
>                 "RSDT")
>                 GTester: last random seed: 
> R02S9eefaf38297e67e4f67d5db77989350e
>                 /home/petmay01/linaro/qemu-for-merges/tests/
>                 Makefile.include:826:
>                 recipe for target 'check-qtest-x86_64' failed
> 
> 
>             Couldn't reproduce here. I suspect VM didn't start at all.
>             Am I right to assume this is without KVM?
> 
> 
>         On aarch64 host, definitely without KVM. On x86-64 host,
>         I think it is without KVM but am not totally sure.
> 
>         It may be one of those cases that only triggers if the
>         host is heavily loaded at the time the test is running.
> 
> 
>     (I apologize if the root cause is obvious at this point -- I'm unclear
>     if the discussion is now about understanding the failure, or about ways
>     to mitigate it. I'm assuming the former.)
> 
>     This test can occasionally fail because the test case has to wait until
>     the guest firmware proceeds far enough with executing the ACPI
>     linker/loader script. See RSDP_SLEEP_US and RSDP_TRIES_MAX in
>     acpi_find_vgia(). If the test case pokes at guest RAM "too early", using
>     monitor commands, then the guest fw will not have yet shaped guest RAM
>     as required.
> 
> 
> Yes, it’s definitely a setup time problem.  With the values that are checked
> in, I can’t get it to fail on my setup, but if I wind the numbers down I see
> the same failure as Peter.  So now we have the ages-old problem of “what new
> arbitrary value should I use that will not cause false failures but will
> eventually time out”.  Can you think of an easy way to tell if firmware is
> running so we can make this more state-driven instead of time-dependent?
> 
> 
> 
>     (Again, apologies if this has been obvious all along.)
> 
>     Thanks
>     Laszlo
> 

I suspect the issue is that io thread runs while CPU thread does not.
How about retrieving the clock id of the VCPU thread
with pthread_getcpuclockid, then getting the time with clock_gettime?
Then keep the current limit but make sure it elapsed in
the VCPU thread.

-- 
MST