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

[Michael S. Tsirkin]

On Fri, Jul 14, 2017 at 02:11:27PM +0100, Peter Maydell wrote:
> On 13 July 2017 at 17:38, Michael S. Tsirkin  wrote:
> > It's already a library, I don't think you need changes or refactoring.
> > You can just link boot_sector.c and call boot_sector_test like the pxe
> > test does. If this passes you know all acpi tables are in memory.
> >
> > I'll post a patch.
> 
> Hi -- you asked me on IRC if I could test that "use boot_sector_test"
> patch, but I can't find it in my email archive or in patchwork.
> Did you forget to send it, or has it got lost in transit? If you can
> provide a pointer to a copy I'll give it a test...
> 
> thanks
> -- PMM

Strange - neither can I. I was sure I sent it.
I just resent - pls take a look.

-- 
MST

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

[Peter Maydell]

On 13 July 2017 at 17:38, Michael S. Tsirkin  wrote:
> It's already a library, I don't think you need changes or refactoring.
> You can just link boot_sector.c and call boot_sector_test like the pxe
> test does. If this passes you know all acpi tables are in memory.
>
> I'll post a patch.

Hi -- you asked me on IRC if I could test that "use boot_sector_test"
patch, but I can't find it in my email archive or in patchwork.
Did you forget to send it, or has it got lost in transit? If you can
provide a pointer to a copy I'll give it a test...

thanks
-- PMM

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

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 06:34:33AM -0700, Ben Warren wrote:
> Hi,
> 
> On Jul 13, 2017, at 4:51 AM, Marc-André Lureau 
> 
> wrote:
> 
> Hi
> 
> On Thu, Jul 13, 2017 at 1:32 PM Laszlo Ersek  wrote:
> 
> On 07/13/17 12:47, Peter Maydell wrote:
> > On 12 July 2017 at 00:43, Ben Warren  
> wrote:
> >> 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”.
> >
> > 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.
> >
> > 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é, do you think it would be feasible for the vmcoreinfo unit
> test as well? (Which is derived from the vmgenid unit test.)
> 
> 
> It seems likely.
> 
> Ben, are you going to work on the fix?
> 
> 
> Yes, I will take care of this.  I remember seeing the boot-sector
> synchronization code before, but didn’t really grok it.  This time I’ll dig
> deeper.

It's already a library, I don't think you need changes or refactoring.
You can just link boot_sector.c and call boot_sector_test like the pxe
test does. If this passes you know all acpi tables are in memory.

I'll post a patch.

There's no clever logic around timeout there though - right now your
timeout is 10 seconds while boot_sector_test has a timeout of 90
seconds.

So it is still worth improving to check the per-thread clock imho,
but I agree it's best to rework vm gen id test.
While at it, I think it's best to drop the assumption that vmgenid
is the 1st table in the ssdt.

> Thanks
> -- 
> Marc-André Lureau
> 
> 
> —Ben
> 

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

[Ben Warren via Qemu-devel]

Hi,
> On Jul 13, 2017, at 4:51 AM, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> On Thu, Jul 13, 2017 at 1:32 PM Laszlo Ersek  > wrote:
> On 07/13/17 12:47, Peter Maydell wrote:
> > On 12 July 2017 at 00:43, Ben Warren  > > wrote:
> >> 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”.
> >
> > 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.
> >
> > 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é, do you think it would be feasible for the vmcoreinfo unit
> test as well? (Which is derived from the vmgenid unit test.)
> 
> It seems likely.
> 
> Ben, are you going to work on the fix?
> 
Yes, I will take care of this.  I remember seeing the boot-sector 
synchronization code before, but didn’t really grok it.  This time I’ll dig 
deeper.
> Thanks
> -- 
> Marc-André Lureau

—Ben

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

[Marc-André Lureau]

Hi

On Thu, Jul 13, 2017 at 1:32 PM Laszlo Ersek  wrote:

> On 07/13/17 12:47, Peter Maydell wrote:
> > On 12 July 2017 at 00:43, Ben Warren  wrote:
> >> 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”.
> >
> > 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.
> >
> > 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é, do you think it would be feasible for the vmcoreinfo unit
> test as well? (Which is derived from the vmgenid unit test.)
>

It seems likely.

Ben, are you going to work on the fix?

Thanks
-- 
Marc-André Lureau

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

[Laszlo Ersek]

On 07/13/17 12:47, Peter Maydell wrote:
> On 12 July 2017 at 00:43, Ben Warren  wrote:
>> 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”.
> 
> 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.
> 
> 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é, do you think it would be feasible for the vmcoreinfo unit
test as well? (Which is derived from the vmgenid unit test.)

Thanks!
Laszlo

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

[Peter Maydell]

On 12 July 2017 at 00:43, Ben Warren  wrote:
> 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”.

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.

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?

thanks
-- PMM

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

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

[Ben Warren via Qemu-devel]

Hi Laszlo,

> On Jul 11, 2017, at 3:13 PM, Laszlo Ersek  wrote:
> 
> On 07/11/17 22:42, Peter Maydell wrote:
>> On 11 July 2017 at 20:10, Michael S. Tsirkin  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

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

[Laszlo Ersek]

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

(Again, apologies if this has been obvious all along.)

Thanks
Laszlo

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

[Peter Maydell]

On 11 July 2017 at 20:10, Michael S. Tsirkin  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.

thanks
-- PMM

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 05:49:07PM +0100, Peter Maydell wrote:
> On 11 July 2017 at 16:22, Peter Maydell  wrote:
> > On 11 July 2017 at 16:07, Ben Warren  wrote:
> >> Hi Peter,
> >>> On Jul 11, 2017, at 6:32 AM, Peter Maydell  
> >>> wrote:
> >>> Hi -- this test seems to intermittently fail:
> >>>
> >>> TEST: tests/vmgenid-test... (pid=15466)
> >>>  /i386/vmgenid/vmgenid/set-guid:  **
> >>> ERROR:/home/peter.maydell/qemu/tests/vmgenid-test.c:65:acpi_find_vgia:
> >>> assertion failed (ACPI_ASSERT_CMP
> >>> _str == "RSDT"): ("" == "RSDT")
> >>> FAIL
> >>> GTester: last random seed: R02S27021da892f2124a377287729b848ff8
> >>> (pid=15470)
> >>>  /i386/vmgenid/vmgenid/set-guid-auto: OK
> >>>  /i386/vmgenid/vmgenid/query-monitor: OK
> >>> FAIL: tests/vmgenid-test
> >>>
> >>> (that's an aarch32 build).
> >>>
> >>>
> >> I’ll try to reproduce.  How exactly are the tests called?
> >
> > 'make check V=1', same as usual.
> 
> 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
> 
> thanks
> -- PMM

Couldn't reproduce here. I suspect VM didn't start at all.
Am I right to assume this is without KVM?

-- 
MST

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

[Peter Maydell]

On 11 July 2017 at 16:22, Peter Maydell  wrote:
> On 11 July 2017 at 16:07, Ben Warren  wrote:
>> Hi Peter,
>>> On Jul 11, 2017, at 6:32 AM, Peter Maydell  wrote:
>>> Hi -- this test seems to intermittently fail:
>>>
>>> TEST: tests/vmgenid-test... (pid=15466)
>>>  /i386/vmgenid/vmgenid/set-guid:  **
>>> ERROR:/home/peter.maydell/qemu/tests/vmgenid-test.c:65:acpi_find_vgia:
>>> assertion failed (ACPI_ASSERT_CMP
>>> _str == "RSDT"): ("" == "RSDT")
>>> FAIL
>>> GTester: last random seed: R02S27021da892f2124a377287729b848ff8
>>> (pid=15470)
>>>  /i386/vmgenid/vmgenid/set-guid-auto: OK
>>>  /i386/vmgenid/vmgenid/query-monitor: OK
>>> FAIL: tests/vmgenid-test
>>>
>>> (that's an aarch32 build).
>>>
>>>
>> I’ll try to reproduce.  How exactly are the tests called?
>
> 'make check V=1', same as usual.

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

thanks
-- PMM

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

[Peter Maydell]

On 11 July 2017 at 16:07, Ben Warren  wrote:
> Hi Peter,
>> On Jul 11, 2017, at 6:32 AM, Peter Maydell  wrote:
>>
>> On 3 July 2017 at 20:45, Michael S. Tsirkin  wrote:
>>> From: Ben Warren 
>>>
>>> The following tests are implemented:
>>> * test that a GUID passed in by command line is propagated to the guest.
>>>  Read the GUID from guest memory
>>> * test that the "auto" argument to the GUID generates a valid GUID, as
>>>  seen by the guest.
>>> * test that a GUID passed in can be queried from the monitor
>>>
>>>  This patch is loosely based on a previous patch from:
>>>  Gal Hammer   and Igor Mammedov 
>>>
>>> Signed-off-by: Ben Warren 
>>> Reviewed-by: Igor Mammedov 
>>> Reviewed-by: Marc-André Lureau 
>>> Reviewed-by: Michael S. Tsirkin 
>>> Signed-off-by: Michael S. Tsirkin 
>>
>> Hi -- this test seems to intermittently fail:
>>
>> TEST: tests/vmgenid-test... (pid=15466)
>>  /i386/vmgenid/vmgenid/set-guid:  **
>> ERROR:/home/peter.maydell/qemu/tests/vmgenid-test.c:65:acpi_find_vgia:
>> assertion failed (ACPI_ASSERT_CMP
>> _str == "RSDT"): ("" == "RSDT")
>> FAIL
>> GTester: last random seed: R02S27021da892f2124a377287729b848ff8
>> (pid=15470)
>>  /i386/vmgenid/vmgenid/set-guid-auto: OK
>>  /i386/vmgenid/vmgenid/query-monitor: OK
>> FAIL: tests/vmgenid-test
>>
>> (that's an aarch32 build).
>>
>>
> I’ll try to reproduce.  How exactly are the tests called?

'make check V=1', same as usual.

I did a manual run of just this test, with
while QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386 gtester -k
--verbose -m=quick tests/vmgenid-test ;do true ;done

but that didn't seem to fall over, so either the test is very
intermittently flaky, or it depends on load on the machine or
something.

thanks
-- PMM

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

[Ben Warren via Qemu-devel]

Hi Peter,
> On Jul 11, 2017, at 6:32 AM, Peter Maydell  wrote:
> 
> On 3 July 2017 at 20:45, Michael S. Tsirkin  wrote:
>> From: Ben Warren 
>> 
>> The following tests are implemented:
>> * test that a GUID passed in by command line is propagated to the guest.
>>  Read the GUID from guest memory
>> * test that the "auto" argument to the GUID generates a valid GUID, as
>>  seen by the guest.
>> * test that a GUID passed in can be queried from the monitor
>> 
>>  This patch is loosely based on a previous patch from:
>>  Gal Hammer   and Igor Mammedov 
>> 
>> Signed-off-by: Ben Warren 
>> Reviewed-by: Igor Mammedov 
>> Reviewed-by: Marc-André Lureau 
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
> 
> Hi -- this test seems to intermittently fail:
> 
> TEST: tests/vmgenid-test... (pid=15466)
>  /i386/vmgenid/vmgenid/set-guid:  **
> ERROR:/home/peter.maydell/qemu/tests/vmgenid-test.c:65:acpi_find_vgia:
> assertion failed (ACPI_ASSERT_CMP
> _str == "RSDT"): ("" == "RSDT")
> FAIL
> GTester: last random seed: R02S27021da892f2124a377287729b848ff8
> (pid=15470)
>  /i386/vmgenid/vmgenid/set-guid-auto: OK
>  /i386/vmgenid/vmgenid/query-monitor: OK
> FAIL: tests/vmgenid-test
> 
> (that's an aarch32 build).
> 
> 
I’ll try to reproduce.  How exactly are the tests called?
> Earlier in the run I see there was also a warning from acpi-test:
> 
>  /i386/acpi/q35/memhp:
> "kvm" accelerator not found.
> 
> Looking for expected file 'tests/acpi-test-data/q35/DSDT.memhp'
> 
> Using expected file 'tests/acpi-test-data/q35/DSDT.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/APIC.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/APIC'
> 
> Using expected file 'tests/acpi-test-data/q35/APIC'
> 
> Looking for expected file 'tests/acpi-test-data/q35/HPET.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/HPET'
> 
> Using expected file 'tests/acpi-test-data/q35/HPET'
> 
> Looking for expected file 'tests/acpi-test-data/q35/SRAT.memhp'
> 
> Using expected file 'tests/acpi-test-data/q35/SRAT.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/SLIT.memhp'
> 
> Using expected file 'tests/acpi-test-data/q35/SLIT.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/MCFG.memhp'
> 
> Looking for expected file 'tests/acpi-test-data/q35/MCFG'
> 
> Using expected file 'tests/acpi-test-data/q35/MCFG'
> acpi-test: Warning! DSDT mismatch. Actual [asl:/tmp/asl-E3X12Y.dsl,
> aml:/tmp/aml-GIX12Y], Expected [asl:/tmp/asl-5Z502Y.dsl,
> aml:tests/acpi-test-data/q35/DSDT.memhp].
> acpi-test: Warning. not showing difference since no diff utility is
> specified. Set 'DIFF' environment variable to a preferred diff utility
> and run 'make V=1 check' again to see ASL difference.OK
> 
> (Shouldn't a DSDT mismatch cause a test failure?)
> 
> 
> thanks
> -- PMM

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

[Peter Maydell]

On 3 July 2017 at 20:45, Michael S. Tsirkin  wrote:
> From: Ben Warren 
>
> The following tests are implemented:
> * test that a GUID passed in by command line is propagated to the guest.
>   Read the GUID from guest memory
> * test that the "auto" argument to the GUID generates a valid GUID, as
>   seen by the guest.
> * test that a GUID passed in can be queried from the monitor
>
>   This patch is loosely based on a previous patch from:
>   Gal Hammer   and Igor Mammedov 
>
> Signed-off-by: Ben Warren 
> Reviewed-by: Igor Mammedov 
> Reviewed-by: Marc-André Lureau 
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 

Hi -- this test seems to intermittently fail:

TEST: tests/vmgenid-test... (pid=15466)
  /i386/vmgenid/vmgenid/set-guid:  **
ERROR:/home/peter.maydell/qemu/tests/vmgenid-test.c:65:acpi_find_vgia:
assertion failed (ACPI_ASSERT_CMP
_str == "RSDT"): ("" == "RSDT")
FAIL
GTester: last random seed: R02S27021da892f2124a377287729b848ff8
(pid=15470)
  /i386/vmgenid/vmgenid/set-guid-auto: OK
  /i386/vmgenid/vmgenid/query-monitor: OK
FAIL: tests/vmgenid-test

(that's an aarch32 build).


Earlier in the run I see there was also a warning from acpi-test:

  /i386/acpi/q35/memhp:
"kvm" accelerator not found.

Looking for expected file 'tests/acpi-test-data/q35/DSDT.memhp'

Using expected file 'tests/acpi-test-data/q35/DSDT.memhp'

Looking for expected file 'tests/acpi-test-data/q35/APIC.memhp'

Looking for expected file 'tests/acpi-test-data/q35/APIC'

Using expected file 'tests/acpi-test-data/q35/APIC'

Looking for expected file 'tests/acpi-test-data/q35/HPET.memhp'

Looking for expected file 'tests/acpi-test-data/q35/HPET'

Using expected file 'tests/acpi-test-data/q35/HPET'

Looking for expected file 'tests/acpi-test-data/q35/SRAT.memhp'

Using expected file 'tests/acpi-test-data/q35/SRAT.memhp'

Looking for expected file 'tests/acpi-test-data/q35/SLIT.memhp'

Using expected file 'tests/acpi-test-data/q35/SLIT.memhp'

Looking for expected file 'tests/acpi-test-data/q35/MCFG.memhp'

Looking for expected file 'tests/acpi-test-data/q35/MCFG'

Using expected file 'tests/acpi-test-data/q35/MCFG'
acpi-test: Warning! DSDT mismatch. Actual [asl:/tmp/asl-E3X12Y.dsl,
aml:/tmp/aml-GIX12Y], Expected [asl:/tmp/asl-5Z502Y.dsl,
aml:tests/acpi-test-data/q35/DSDT.memhp].
acpi-test: Warning. not showing difference since no diff utility is
specified. Set 'DIFF' environment variable to a preferred diff utility
and run 'make V=1 check' again to see ASL difference.OK

(Shouldn't a DSDT mismatch cause a test failure?)


thanks
-- PMM