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 <ler...@redhat.com> wrote: > > On 07/11/17 22:42, Peter Maydell wrote: > > On 11 July 2017 at 20:10, Michael S. Tsirkin <m...@redhat.com> 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