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

[Ben Warren]

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