All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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 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.