[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/3] qtest: pick tests that require KVM at runtime
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [RFC 0/3] qtest: pick tests that require KVM at runtime |
Date: |
Tue, 22 Jun 2021 10:22:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 |
On 6/22/21 10:07 AM, Alex Bennée wrote:
> Igor Mammedov <imammedo@redhat.com> writes:
>> On Fri, 18 Jun 2021 14:43:46 +0200
>> Claudio Fontana <cfontana@suse.de> wrote:
>>> On 6/18/21 1:26 PM, Igor Mammedov wrote:
>>>> On Thu, 17 Jun 2021 18:49:17 +0200
>>>> Claudio Fontana <cfontana@suse.de> wrote:
>>>>> On 6/16/21 5:24 PM, Igor Mammedov wrote:
>>>>>>
>>>>>> Sometimes it's necessary to execute a test that depends on KVM,
>>>>>> however qtest is not aware if tested QEMU binary supports KVM
>>>>>> on the host it the test is executed.
>>>>>
>>>>> Hello,
>>>>>
>>>>> It seems to me that we are constantly re-implementing the same feature
>>>>> with slight variations?
>>>>>
>>>>> Didn't we have a generic series to introduce qtest_has_accel() from
>>>>> Philippe before?
>>>> It's mentioned in cover letter (PS: part) and in [1/3] with rationale
>>>> why this was posted.
>>>
>>> Thought it was separate, but now I see that it uses query-accel underneath.
>>>
>>> Seems strange to add another check to do the same thing, it may point to
>>> qtest_has_accel() needing some update?
>>> You mention it is time consuming to use qtest_has_accel(), have you
>>> measured an important overhead?
>>> With qtest_has_accel() not even being committed yet, is it already
>>> necessary to work around it because it's too slow?
>>
>> Tests are already take a lot of time as is, so I'd try to avoid slowing
>> them down.
>>
>> proposed qtest_has_accel() requires spawning QEMU to probe, which is slow.
>> Worst case would be:
>> = qemu startup time * number of checks * number of targets
>>
>> It's fine to run occasionally, I can take a coffee break while tests run.
>> But put it in context of CI and it multiplies by the number of push requests
>> and starts to eat not only time but also limited CI resources.
>>
>> In current form qtest_has_accel() is only marginally better functionality
>> wise, as it reports all built in accelerators while qtest_has_kvm() accounts
>> only for KVM.
>>
>> qtest_has_kvm() is collecting info about built-in accelerators at
>> configure/build time and that probably could be extended to other
>> accelerators (not a thing that I'm interested in at the moment).
>> So it could be extended to support the same accelerators
>> as currently proposed qtest_has_accel().
>
> One minor downside is this forever ties the tests to the build. I have
> spoken with people before about the idea of separating the test
> artefacts from the build so they can be used either as a) cached test
> objects or b) other testing environments, for example verifying the
> kernel has not regressed. However we don't do either of those things at
> the moment so it's not a major concern.
This is the feature that is interesting RedHat QE too, run the latest
qtests on various released binaries to compare performances between
releases.
> If the worry is about extending test times by having an extra round trip
> of a spawn and query step for every test could we not consider caching
> the information somewhere? Really any given binary should only need to
> be queried once per run, not per test.
Good idea.
>> Given a less expensive approach exists, the qtest_has_accel()
>> in its current form might be not justifiable.
>>
>>
>>>>> Does this series work with --disable-kvm builds? (TCG-only builds?)
>>>> I'll test. But on the first glance it should work without issues.
>>>> (i.e. kvm only tests will be skipped).
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> CLaudio
>>>>>
>>>>>
>>>>>>
>>>>>> For an example:
>>>>>> test q35 machine with intel_iommu
>>>>>> This test will run only is KVM is available and fail
>>>>>> to start QEMU if it fallsback to TCG, thus failing whole test.
>>>>>> So if test is executed in VM where nested KVM is not enabled
>>>>>> or on other than x86 host, it will break 'make check-qtest'
>>>>>>
>>>>>> Series adds a lightweight qtest_has_kvm() check, which abuses
>>>>>> build system and should help to avoid running KVM only tests
>>>>>> on hosts that do not support it.
>>>>>>
>>>>>> PS:
>>>>>> there is an alternative 'query-accels' QMP command proposal
>>>>>> https://patchwork.kernel.org/project/qemu-devel/patch/20210503211020.894589-3-philmd@redhat.com/
>>>>>> which I think is more robust compared to qtest_has_kvm() and
>>>>>> could be extended to take into account machine type.
>>>>>> But it's more complex and what I dislike about it most,
>>>>>> it requires execution of 'probing' QEMU instance to find
>>>>>> execute 'query-accels' QMP command, which is rather resource
>>>>>> consuming. So I'd use query-accels approach only when it's
>>>>>> the only possible option to minimize load on CI systems.
>>>>>>
>>>>>> Igor Mammedov (2):
>>>>>> tests: acpi: q35: test for x2APIC entries in SRAT
>>>>>> tests: acpi: update expected tables blobs
>>>>>>
>>>>>> root (1):
>>>>>> tests: qtest: add qtest_has_kvm() to check if tested bynary supports
>>>>>> KVM
>>>>>>
>>>>>> tests/qtest/libqos/libqtest.h | 7 +++++++
>>>>>> meson.build | 1 +
>>>>>> tests/data/acpi/q35/APIC.numamem | Bin 0 -> 2686 bytes
>>>>>> tests/data/acpi/q35/DSDT.numamem | Bin 7865 -> 35222 bytes
>>>>>> tests/data/acpi/q35/FACP.numamem | Bin 0 -> 244 bytes
>>>>>> tests/data/acpi/q35/SRAT.numamem | Bin 224 -> 5080 bytes
>>>>>> tests/qtest/bios-tables-test.c | 10 +++++++---
>>>>>> tests/qtest/libqtest.c | 20 ++++++++++++++++++++
>>>>>> 8 files changed, 35 insertions(+), 3 deletions(-)
>>>>>> create mode 100644 tests/data/acpi/q35/APIC.numamem
>>>>>> create mode 100644 tests/data/acpi/q35/FACP.numamem
>>>>>>
>>>>>
>>>>
>>>
>
>
- [RFC v2 1/3] tests: qtest: add qtest_has_kvm() to check if tested binary supports KVM, (continued)
- [RFC 3/3] tests: acpi: update expected tables blobs, Igor Mammedov, 2021/06/16
- [RFC 2/3] tests: acpi: q35: test for x2APIC entries in SRAT, Igor Mammedov, 2021/06/16
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, no-reply, 2021/06/16
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Claudio Fontana, 2021/06/17
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Igor Mammedov, 2021/06/18
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Claudio Fontana, 2021/06/18
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Igor Mammedov, 2021/06/18
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Alex Bennée, 2021/06/22
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime,
Philippe Mathieu-Daudé <=
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Igor Mammedov, 2021/06/22
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Philippe Mathieu-Daudé, 2021/06/22
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Igor Mammedov, 2021/06/18
- Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Claudio Fontana, 2021/06/22
Re: [RFC 0/3] qtest: pick tests that require KVM at runtime, Thomas Huth, 2021/06/22