From: Eduardo Habkost <ehabkost@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Markus Armbruster" <armbru@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
qemu-devel@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
"Yash Mankad" <ymankad@redhat.com>
Subject: [Qemu-devel] Who is running QEMU automated tests, and when?
Date: Thu, 26 Apr 2018 10:57:55 -0300 [thread overview]
Message-ID: <20180426135755.GI29865@localhost.localdomain> (raw)
(Starting a new thread, for more visibility)
(This was: Re: [Qemu-devel] [RFC PATCH] tests/device-introspect: Test
devices with all machines, not only with "none")
On Thu, Apr 26, 2018 at 01:54:43PM +0200, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> > On 17.04.2018 14:12, Markus Armbruster wrote:
> >> Thomas Huth <thuth@redhat.com> writes:
> >>
> >>> Many device introspection crashes only happen if you are using a
> >>> certain machine, e.g.:
> >>>
> >>> $ ppc-softmmu/qemu-system-ppc -S -M ref405ep,accel=qtest -qmp stdio
> >>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 11, "major": 2},
> >>> "package": "build-all"}, "capabilities": []}}
> >>> { 'execute': 'qmp_capabilities' }
> >>> {"return": {}}
> >>> { 'execute': 'device-list-properties',
> >>> 'arguments': {'typename': 'macio-newworld'}}
> >>> Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:222:
> >>> Device 'serial0' is in use
> >>> Aborted (core dumped)
> >>>
> >>> To be able to catch these problems, let's extend the device-introspect
> >>> test to check the devices on all machine types. Since this is a rather
> >>> slow operation, the test is only run in "SPEED=slow" mode.
> >>
> >> If the device works with one machine type, it has a decent chance to
> >> work with others, too. Thus, testing each device with every machine
> >> type is overkill. I appreciate having overkill as an option :)
> >>
> >> What I'd like to see for a quick "make check" is testing each device
> >> once. That should flush out most bugs.
> >
> > That's already done with the "none" machine.
>
> I was too terse. We test each device with -machine none for every
> target. Fine if that's quick enough. If not, we might want to reduce
> redundancy there.
>
> Actually, a worse offender in the "waste everybody's time via redunancy"
> department could be qom-test.
>
> > Anyway, do you think my patch here is useful and has a chance of getting
> > included? I.e. shall I re-spin this as a non-RFC patch? Or shall we
> > rather wait for Eduardo's python-based tests to get included into the
> > repository?
>
> I don't mind having make check SPEED=slow run more extensive tests.
> Assuming we actually run them at least once in a while, which seems
> doubtful.
We probably don't do that, but we really must be running a more
extensive (and slower) test set at least once before every
release.
Maybe some people are running SPEED=slow tests, or even more
extensive test suites like avocado-vt once in a while, but we
need to know who is running them, and when.
Today, the only test set I know people really run and would
surely block a release is "make check [SPEED=quick]".
So, for anybody that runs automated QEMU tests once in a while,
can we know:
* What test cases are you running? Where can we get more
information about the tests you run?
* When do you run them? What triggers a new test run?
Peter, do you have additional tests you run before merging a pull
request? Additional test sets run before tagging a release?
--
Eduardo
next reply other threads:[~2018-04-26 13:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 13:57 Eduardo Habkost [this message]
2018-04-26 14:04 ` [Qemu-devel] Who is running QEMU automated tests, and when? Peter Maydell
2018-04-26 21:51 ` Michael Clark
2018-05-09 15:53 ` Alex Bennée
2018-05-09 16:25 ` Thomas Huth
2018-04-26 14:09 ` Thomas Huth
2018-04-26 14:14 ` Daniel P. Berrangé
2018-04-26 14:22 ` Eduardo Habkost
2018-04-26 14:24 ` Daniel P. Berrangé
2018-04-27 3:58 ` Thomas Huth
2018-04-27 8:57 ` Daniel P. Berrangé
2018-04-26 14:25 ` Thomas Huth
2018-04-26 15:45 ` Cornelia Huck
2018-04-27 3:10 ` Fam Zheng
2018-04-27 19:23 ` Eduardo Habkost
2018-04-27 14:33 ` Anthony PERARD
2018-04-27 19:13 ` Lukáš Doktor
2018-05-08 9:56 ` Stefan Hajnoczi
2018-05-08 18:13 ` John Snow
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=20180426135755.GI29865@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=ymankad@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).