All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	qemu-devel@nongnu.org
Cc: lvivier@redhat.com, mst@redhat.com
Subject: Re: [RFC 0/3] qtest: pick tests that require KVM at runtime
Date: Tue, 22 Jun 2021 09:59:48 +0200	[thread overview]
Message-ID: <bb1b17d4-6da5-aebf-329a-905dd566ec6b@redhat.com> (raw)
In-Reply-To: <75263d99-5da8-bdc5-e977-13c83a31b532@redhat.com>

On 22/06/2021 09.26, Philippe Mathieu-Daudé wrote:
> On 6/22/21 9:20 AM, Thomas Huth wrote:
>> On 16/06/2021 17.24, 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.
>>>
>>> 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.
>>
>> You also might want to update the check in tests/qtest/migration-test.c
>> while you're at 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.
>>
>> Could you please get in touch with Philippe directly and discuss which
>> way to go? We certainly don't need two approaches in the end...
> 
> I'm certainly fine if Igor wants to restart this effort :)
> 
> Maybe doing as Claudio suggested, start have qtest_has_accel()
> tests accel with Igor's shortpath first, then fallback to
> 'query-accels' QMP command?

Yeah, that's maybe a good idea ...
But I'm currently wondering whether we need query-accels at all? For 
detecting kvm, we already have "query-kvm" ... and we don't have tests for 
any other accelerators yet (hax, hvf, etc.) ... so it's likely just about 
having a way to detect whether TCG is compiled into the binary? Is there 
already another command that could be used to check for the availability of TCG?

  Thomas



  reply	other threads:[~2021-06-22  8:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 15:24 [RFC 0/3] qtest: pick tests that require KVM at runtime Igor Mammedov
2021-06-16 15:24 ` [RFC 1/3] tests: qtest: add qtest_has_kvm() to check if tested binary supports KVM Igor Mammedov
2021-06-17 10:00   ` [RFC v2 " Igor Mammedov
2021-06-17 16:28     ` Igor Mammedov
2021-06-16 15:24 ` [RFC 2/3] tests: acpi: q35: test for x2APIC entries in SRAT Igor Mammedov
2021-06-16 15:24 ` [RFC 3/3] tests: acpi: update expected tables blobs Igor Mammedov
2021-06-16 15:30 ` [RFC 0/3] qtest: pick tests that require KVM at runtime no-reply
2021-06-17 16:49 ` Claudio Fontana
2021-06-18 11:26   ` Igor Mammedov
2021-06-18 12:43     ` Claudio Fontana
2021-06-18 13:29       ` Igor Mammedov
2021-06-22  8:07         ` Alex Bennée
2021-06-22  8:22           ` Philippe Mathieu-Daudé
2021-06-22 10:36             ` Igor Mammedov
2021-06-22 11:27               ` Philippe Mathieu-Daudé
2021-06-18 15:58     ` Igor Mammedov
2021-06-22  6:58       ` Claudio Fontana
2021-06-22  7:20 ` Thomas Huth
2021-06-22  7:26   ` Philippe Mathieu-Daudé
2021-06-22  7:59     ` Thomas Huth [this message]
2021-06-22 10:54       ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb1b17d4-6da5-aebf-329a-905dd566ec6b@redhat.com \
    --to=thuth@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.