kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "David Hildenbrand" <david@redhat.com>,
	kvm@vger.kernel.org, "Radim Krčmář" <rkrcmar@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Cc: "Drew Jones" <drjones@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [kvm-unit-tests PATCH] travis.yml: Enable running of tests with TCG
Date: Fri, 6 Sep 2019 11:54:39 +0200	[thread overview]
Message-ID: <3cc8a3c5-c86f-5b06-bff0-753ef628c7e3@redhat.com> (raw)
In-Reply-To: <b94ed46f-7e50-daae-321c-c01b473ca0ea@redhat.com>

On 06/09/2019 11.43, David Hildenbrand wrote:
> On 30.08.19 20:45, Thomas Huth wrote:
>> Currently the tests at the end of the .travis.yml script are ignored,
>> since we can not use KVM in the Travis containers. But we can actually
>> run of some of the kvm-unit-tests with TCG instead, to make sure that
>> the binaries are not completely broken.
>> Thus introduce a new TESTS variable that lists the tests which we can
>> run with TCG. Unfortunately, the ppc64 and s390x QEMUs in Ubuntu also
>> need some extra love: The ppc64 version only works with the additional
>> "cap-htm=off" setting. And the s390x package lacks the firmware and
>> refuses to work unless we provide a fake firmware file here. Any file
>> works since the firmware is skipped when "-kernel" is used, so we can
>> simply use one of the pre-existing files in the source tree.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>  .travis.yml | 19 ++++++++++++++++++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index a4a165d..6c14953 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -20,24 +20,40 @@ env:
>>    matrix:
>>      - CONFIG=""
>>        BUILD_DIR="."
>> +      TESTS="vmexit_cpuid vmexit_mov_from_cr8 vmexit_mov_to_cr8 vmexit_ipi
>> +             vmexit_ple_round_robin vmexit_tscdeadline vmexit_tscdeadline_immed"
>>      - CONFIG=""
>>        BUILD_DIR="x86-builddir"
>> +      TESTS="ioapic-split ioapic smptest smptest3 eventinj msr port80 syscall
>> +             tsc rmap_chain umip intel_iommu vmexit_inl_pmtimer vmexit_ipi_halt"
>>      - CONFIG="--arch=arm --cross-prefix=arm-linux-gnueabihf-"
>>        BUILD_DIR="."
>> +      TESTS="selftest-vectors-kernel selftest-vectors-user selftest-smp"
>>      - CONFIG="--arch=arm --cross-prefix=arm-linux-gnueabihf-"
>>        BUILD_DIR="arm-buildir"
>> +      TESTS="pci-test pmu gicv2-active gicv3-active psci selftest-setup"
>>      - CONFIG="--arch=arm64 --cross-prefix=aarch64-linux-gnu-"
>>        BUILD_DIR="."
>> +      TESTS="selftest-vectors-kernel selftest-vectors-user selftest-smp"
>>      - CONFIG="--arch=arm64 --cross-prefix=aarch64-linux-gnu-"
>>        BUILD_DIR="arm64-buildir"
>> +      TESTS="pci-test pmu gicv2-active gicv3-active psci timer selftest-setup"
>>      - CONFIG="--arch=ppc64 --endian=little --cross-prefix=powerpc64le-linux-gnu-"
>>        BUILD_DIR="."
>> +      TESTS="spapr_hcall emulator rtas-set-time-of-day"
>> +      ACCEL="tcg,cap-htm=off"
>>      - CONFIG="--arch=ppc64 --endian=little --cross-prefix=powerpc64le-linux-gnu-"
>>        BUILD_DIR="ppc64le-buildir"
>> +      TESTS="rtas-get-time-of-day rtas-get-time-of-day-base"
>> +      ACCEL="tcg,cap-htm=off"
>>      - CONFIG="--arch=s390x --cross-prefix=s390x-linux-gnu-"
>>        BUILD_DIR="."
>> +      TESTS="diag10 diag308"
>> +      ACCEL="tcg,firmware=s390x/run"
>>      - CONFIG="--arch=s390x --cross-prefix=s390x-linux-gnu-"
>>        BUILD_DIR="s390x-builddir"
>> +      TESTS="sieve"
>> +      ACCEL="tcg,firmware=s390x/run"
> 
> What about the other s390x tests? (is the QEMU binary too old to make
> them pass?)

Yes. All the others are failing.

> The issue with TCG is that you can easily get false negatives in case
> the QEMU binary changes (e.g., new Ubuntu release).

That should not be a big deal, since the Ubuntu version is locked to a
certain release in the travis.yml file. So we should not get a new
version of QEMU by accident here, only if we explicitly update the
"dist:" line in the yml file.

> "to make sure that the binaries are not completely broken" - while I
> understand the intuition behind that, I wonder if this is relevant in
> practice
Well, the test coverage here is certainly far from being perfect, but
it's still better than nothing. Imagine one of the patches changes
common code in the lib/ folder and it only works on one architecture
that the author tested. Chances are quite good that we detect that
problem with this patch now.

 Thomas

  reply	other threads:[~2019-09-06  9:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 18:45 [kvm-unit-tests PATCH] travis.yml: Enable running of tests with TCG Thomas Huth
2019-09-06  9:43 ` David Hildenbrand
2019-09-06  9:54   ` Thomas Huth [this message]
2019-09-06 10:02     ` David Hildenbrand
2019-09-06 10:10       ` Thomas Huth
2019-09-10 14:50 ` Paolo Bonzini

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=3cc8a3c5-c86f-5b06-bff0-753ef628c7e3@redhat.com \
    --to=thuth@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).