From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVcLe-0004Fu-Mp for qemu-devel@nongnu.org; Thu, 13 Jul 2017 07:31:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVcLZ-00049d-Pn for qemu-devel@nongnu.org; Thu, 13 Jul 2017 07:31:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45860) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVcLZ-00049R-Jo for qemu-devel@nongnu.org; Thu, 13 Jul 2017 07:31:53 -0400 References: <1499111049-13721-1-git-send-email-mst@redhat.com> <1499111049-13721-20-git-send-email-mst@redhat.com> <7EC3FA95-777F-4F8F-B02D-85FA09BAFC00@skyportsystems.com> <20170711220915-mutt-send-email-mst@kernel.org> <273a7da7-2243-171f-e96d-39e8e8031984@redhat.com> <3CA8C399-80D0-4BC8-ACC6-FD72A09D9685@skyportsystems.com> From: Laszlo Ersek Message-ID: <06cbc0c4-73bc-d527-a466-de5a05b0641e@redhat.com> Date: Thu, 13 Jul 2017 13:31:45 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Ben Warren Cc: "Michael S. Tsirkin" , Igor Mammedov , QEMU Developers , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= On 07/13/17 12:47, Peter Maydell wrote: > On 12 July 2017 at 00:43, Ben Warren wrote: >> Yes, it=E2=80=99s definitely a setup time problem. With the values th= at are checked >> in, I can=E2=80=99t get it to fail on my setup, but if I wind the numb= ers down I see >> the same failure as Peter. So now we have the ages-old problem of =E2= =80=9Cwhat new >> arbitrary value should I use that will not cause false failures but wi= ll >> eventually time out=E2=80=9D. >=20 > Empirically, we already have an answer to this, in the form > of the existing code in tests/boot-sector.c, which is used > by both that test and the bios-tables-test.c code to wait > for the BIOS initialization to complete, and which doesn't > cause false test timeouts in practice. >=20 > Can we make this test just use that existing function to > wait for the BIOS to be done, rather than having its own > timeout loop? This is incredibly cool. Now that I've looked at "tests/boot-sector.c" (again), I recall having seen it earlier, but I couldn't have remembered it off-hand. Perhaps this boot sector code should be factored out and moved to "tests/acpi-utils". Marc-Andr=C3=A9, do you think it would be feasible for the vmcoreinfo uni= t test as well? (Which is derived from the vmgenid unit test.) Thanks! Laszlo