On 6/22/21 10:07 AM, Alex Bennée wrote: > Igor Mammedov <imamm...@redhat.com> writes: >> On Fri, 18 Jun 2021 14:43:46 +0200 >> Claudio Fontana <cfont...@suse.de> wrote: >>> On 6/18/21 1:26 PM, Igor Mammedov wrote: >>>> On Thu, 17 Jun 2021 18:49:17 +0200 >>>> Claudio Fontana <cfont...@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-phi...@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 >>>>>> >>>>> >>>> >>> > >
