All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none"
Date: Mon, 7 May 2018 16:32:20 -0300	[thread overview]
Message-ID: <20180507193220.GF25013@localhost.localdomain> (raw)
In-Reply-To: <4bba0be5-a52c-48ad-3df4-4e9be3624dc0@redhat.com>

On Mon, May 07, 2018 at 09:13:57PM +0200, Thomas Huth wrote:
> On 07.05.2018 20:21, Eduardo Habkost wrote:
> > On Mon, May 07, 2018 at 06:50:35PM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost <ehabkost@redhat.com> writes:
> >>
> >>> On Fri, Apr 27, 2018 at 08:31:58AM +0200, Markus Armbruster wrote:
> >>>> Eduardo Habkost <ehabkost@redhat.com> writes:
> >>>>
> >>>>> On Thu, Apr 26, 2018 at 05:20:25PM +0200, Thomas Huth wrote:
> >>>>>> On 26.04.2018 13:45, Markus Armbruster wrote:
> >>>>>>> Thomas Huth <thuth@redhat.com> writes:
> >>>>>> [...]
> >>>>>>>> @@ -260,6 +263,26 @@ static void test_abstract_interfaces(void)
> >>>>>>>>      qtest_end();
> >>>>>>>>  }
> >>>>>>>>  
> >>>>>>>> +static void add_machine_test_case(const char *mname)
> >>>>>>>> +{
> >>>>>>>> +    char *path, *args;
> >>>>>>>> +
> >>>>>>>> +    /* Ignore blacklisted machines */
> >>>>>>>> +    if (g_str_equal("xenfv", mname) || g_str_equal("xenpv", mname)) {
> >>>>>>>> +        return;
> >>>>>>>> +    }
> >>>>>>>> +
> >>>>>>>> +    path = g_strdup_printf("device/introspect/concrete-defaults-%s", mname);
> >>>>>>>> +    args = g_strdup_printf("-machine %s", mname);
> >>>>>>>> +    qtest_add_data_func(path, args, test_device_intro_concrete);
> >>>>>>>
> >>>>>>> This runs test_device_intro_concrete() with "-machine M" for all machine
> >>>>>>> types M, in SPEED=slow mode.
> >>>>>>>
> >>>>>>>> +    g_free(path);
> >>>>>>>> +
> >>>>>>>> +    path = g_strdup_printf("device/introspect/concrete-nodefaults-%s", mname);
> >>>>>>>> +    args = g_strdup_printf("-nodefaults -machine %s", mname);
> >>>>>>>> +    qtest_add_data_func(path, args, test_device_intro_concrete);
> >>>>>>>
> >>>>>>> This runs test_device_intro_concrete() with "-nodefaults -machine M" for
> >>>>>>> all machine types M, in SPEED=slow mode.
> >>>>>>>
> >>>>>>> Has "without -nodefaults" exposed additional bugs?
> >>>>>>
> >>>>>> After testing this with all machines, I had to discover that
> >>>>>> "-nodefaults" does not work so easily: A lot of the embedded machines
> >>>>>> (especially the ARM machines) simply refuse to work with "-nodefaults"
> >>>>>> and exit immediately instead. E.g.:
> >>>>>>
> >>>>>> $ arm-softmmu/qemu-system-arm -nodefaults -nographic -M n810,accel=qtest
> >>>>>> qemu-system-arm: missing SecureDigital device
> >>>>
> >>>> These are all bugs.  --nodefaults is supposed to suppress *optional*
> >>>> devices, not mandatory ones.
> >>>
> >>> I'm not sure I understand the requirements.  What exactly is the
> >>> definition of "mandatory"?
> >>>
> >>> A machine created by "qemu-system-x86_64 -machine pc -nodefaults"
> >>> is useless because it has no any device to boot from.  How is
> >>> that different from a n810 machine not booting because there's no
> >>> SD device?
> >>
> >> I propose:
> >>
> >> * Stuff that's required for QEMU to run is not suppressed by -nodefaults
> >>
> >> * Stuff that a real machine has soldered on is also not suppressed
> >>
> >> * Stuff that can be pulled out of a real machine may be suppressed, even
> >>   when that means the guest won't run
> > 
> > Makes sense to me.  It looks like the only obstacle for
> > tests/device-introspect and device-crash-test is the first rule.
> > "Guest won't boot" isn't a problem, but "QEMU won't run" is.
> > 
> > The first rule is easily testable, too: running
> > "$QEMU -machine $MACHINE -nodefaults" and not having a working
> > QMP monitor should be reported as a bug by automated tests.
> 
> You mean with "-accel qtest" or without? With "-accel qtest" we should
> pretty soon be fine, after Peter's current PULL request has been merged
> (which contains a patch from me for fixing these SD card problems with
> ARM machines).
> Without "-accel qtest", things are not that easy, unfortunately. Lots of
> boards require "-kernel" or "-bios" and refuse to work without. So you
> can hardly test "-nodefaults" automatically in the normal tcg mode. (But
> maybe all boards should allow to start QEMU in case you've at least also
> specified "-S" ? ... in that case we've got plenty of work for
> BiteSizeTasks ;-) )

Hmm, maybe it's not a bite-sized task after all.  :)

Should we do this gradually?

* Working with -accel qtest is useful, and sounds like an easier goal;
* working with -S seems desirable too;
* working without -S (even if the emulated CPU crashes and burns)
  would be interesting.

Related question: what are the use cases where we require
"-accel qtest" and "-S" wouldn't work?

Are the requirements and goals of "-accel qtest" documented
somewhere?  Without documentation, it's hard to say when a given
qtest_enabled() call in the code is reasonable, or a hack we want
to get rid of.

-- 
Eduardo

WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none"
Date: Mon, 7 May 2018 16:32:20 -0300	[thread overview]
Message-ID: <20180507193220.GF25013@localhost.localdomain> (raw)
In-Reply-To: <4bba0be5-a52c-48ad-3df4-4e9be3624dc0@redhat.com>

On Mon, May 07, 2018 at 09:13:57PM +0200, Thomas Huth wrote:
> On 07.05.2018 20:21, Eduardo Habkost wrote:
> > On Mon, May 07, 2018 at 06:50:35PM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost <ehabkost@redhat.com> writes:
> >>
> >>> On Fri, Apr 27, 2018 at 08:31:58AM +0200, Markus Armbruster wrote:
> >>>> Eduardo Habkost <ehabkost@redhat.com> writes:
> >>>>
> >>>>> On Thu, Apr 26, 2018 at 05:20:25PM +0200, Thomas Huth wrote:
> >>>>>> On 26.04.2018 13:45, Markus Armbruster wrote:
> >>>>>>> Thomas Huth <thuth@redhat.com> writes:
> >>>>>> [...]
> >>>>>>>> @@ -260,6 +263,26 @@ static void test_abstract_interfaces(void)
> >>>>>>>>      qtest_end();
> >>>>>>>>  }
> >>>>>>>>  
> >>>>>>>> +static void add_machine_test_case(const char *mname)
> >>>>>>>> +{
> >>>>>>>> +    char *path, *args;
> >>>>>>>> +
> >>>>>>>> +    /* Ignore blacklisted machines */
> >>>>>>>> +    if (g_str_equal("xenfv", mname) || g_str_equal("xenpv", mname)) {
> >>>>>>>> +        return;
> >>>>>>>> +    }
> >>>>>>>> +
> >>>>>>>> +    path = g_strdup_printf("device/introspect/concrete-defaults-%s", mname);
> >>>>>>>> +    args = g_strdup_printf("-machine %s", mname);
> >>>>>>>> +    qtest_add_data_func(path, args, test_device_intro_concrete);
> >>>>>>>
> >>>>>>> This runs test_device_intro_concrete() with "-machine M" for all machine
> >>>>>>> types M, in SPEED=slow mode.
> >>>>>>>
> >>>>>>>> +    g_free(path);
> >>>>>>>> +
> >>>>>>>> +    path = g_strdup_printf("device/introspect/concrete-nodefaults-%s", mname);
> >>>>>>>> +    args = g_strdup_printf("-nodefaults -machine %s", mname);
> >>>>>>>> +    qtest_add_data_func(path, args, test_device_intro_concrete);
> >>>>>>>
> >>>>>>> This runs test_device_intro_concrete() with "-nodefaults -machine M" for
> >>>>>>> all machine types M, in SPEED=slow mode.
> >>>>>>>
> >>>>>>> Has "without -nodefaults" exposed additional bugs?
> >>>>>>
> >>>>>> After testing this with all machines, I had to discover that
> >>>>>> "-nodefaults" does not work so easily: A lot of the embedded machines
> >>>>>> (especially the ARM machines) simply refuse to work with "-nodefaults"
> >>>>>> and exit immediately instead. E.g.:
> >>>>>>
> >>>>>> $ arm-softmmu/qemu-system-arm -nodefaults -nographic -M n810,accel=qtest
> >>>>>> qemu-system-arm: missing SecureDigital device
> >>>>
> >>>> These are all bugs.  --nodefaults is supposed to suppress *optional*
> >>>> devices, not mandatory ones.
> >>>
> >>> I'm not sure I understand the requirements.  What exactly is the
> >>> definition of "mandatory"?
> >>>
> >>> A machine created by "qemu-system-x86_64 -machine pc -nodefaults"
> >>> is useless because it has no any device to boot from.  How is
> >>> that different from a n810 machine not booting because there's no
> >>> SD device?
> >>
> >> I propose:
> >>
> >> * Stuff that's required for QEMU to run is not suppressed by -nodefaults
> >>
> >> * Stuff that a real machine has soldered on is also not suppressed
> >>
> >> * Stuff that can be pulled out of a real machine may be suppressed, even
> >>   when that means the guest won't run
> > 
> > Makes sense to me.  It looks like the only obstacle for
> > tests/device-introspect and device-crash-test is the first rule.
> > "Guest won't boot" isn't a problem, but "QEMU won't run" is.
> > 
> > The first rule is easily testable, too: running
> > "$QEMU -machine $MACHINE -nodefaults" and not having a working
> > QMP monitor should be reported as a bug by automated tests.
> 
> You mean with "-accel qtest" or without? With "-accel qtest" we should
> pretty soon be fine, after Peter's current PULL request has been merged
> (which contains a patch from me for fixing these SD card problems with
> ARM machines).
> Without "-accel qtest", things are not that easy, unfortunately. Lots of
> boards require "-kernel" or "-bios" and refuse to work without. So you
> can hardly test "-nodefaults" automatically in the normal tcg mode. (But
> maybe all boards should allow to start QEMU in case you've at least also
> specified "-S" ? ... in that case we've got plenty of work for
> BiteSizeTasks ;-) )

Hmm, maybe it's not a bite-sized task after all.  :)

Should we do this gradually?

* Working with -accel qtest is useful, and sounds like an easier goal;
* working with -S seems desirable too;
* working without -S (even if the emulated CPU crashes and burns)
  would be interesting.

Related question: what are the use cases where we require
"-accel qtest" and "-S" wouldn't work?

Are the requirements and goals of "-accel qtest" documented
somewhere?  Without documentation, it's hard to say when a given
qtest_enabled() call in the code is reasonable, or a hack we want
to get rid of.

-- 
Eduardo

  reply	other threads:[~2018-05-07 19:32 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19  9:39 [Qemu-arm] [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none" Thomas Huth
2018-03-19  9:39 ` [Qemu-devel] " Thomas Huth
2018-03-19 20:37 ` [Qemu-arm] " Eduardo Habkost
2018-03-19 20:37   ` [Qemu-devel] " Eduardo Habkost
2018-04-17 12:12 ` [Qemu-arm] " Markus Armbruster
2018-04-17 12:12   ` Markus Armbruster
2018-04-17 12:52   ` [Qemu-arm] " Peter Maydell
2018-04-17 12:52     ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2018-04-17 13:15     ` [Qemu-arm] [Qemu-devel] " Markus Armbruster
2018-04-17 13:15       ` [Qemu-devel] [Qemu-arm] " Markus Armbruster
2018-04-26 10:24   ` [Qemu-arm] [Qemu-devel] " Thomas Huth
2018-04-26 10:24     ` Thomas Huth
2018-04-26 11:54     ` [Qemu-arm] " Markus Armbruster
2018-04-26 11:54       ` Markus Armbruster
2018-04-26 15:27       ` [Qemu-arm] " Thomas Huth
2018-04-26 15:27         ` Thomas Huth
2018-04-27  0:34       ` [Qemu-arm] " Eduardo Habkost
2018-04-27  0:34         ` Eduardo Habkost
2018-04-27  3:45         ` [Qemu-arm] " Thomas Huth
2018-04-27  3:45           ` Thomas Huth
2018-04-27  6:06       ` [Qemu-arm] [Qemu-devel] qom-test (was: [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none") Thomas Huth
2018-04-27  6:06         ` Thomas Huth
2018-04-27  6:29         ` [Qemu-arm] [Qemu-devel] qom-test Markus Armbruster
2018-04-27  6:29           ` Markus Armbruster
2018-04-27 10:20         ` [Qemu-arm] [Qemu-devel] qom-test (was: [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none") Peter Maydell
2018-04-27 10:20           ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2018-04-27 10:24           ` [Qemu-devel] [Qemu-arm] qom-test Thomas Huth
2018-04-27 10:24             ` Thomas Huth
2018-04-27 16:30             ` [Qemu-arm] [Qemu-devel] qom-test Markus Armbruster
2018-04-27 16:30               ` [Qemu-devel] [Qemu-arm] qom-test Markus Armbruster
2018-04-27 16:36               ` [Qemu-arm] [Qemu-ppc] [Qemu-devel] qom-test Thomas Huth
2018-04-27 16:36                 ` [Qemu-devel] [Qemu-ppc] [Qemu-arm] qom-test Thomas Huth
2018-04-26 11:45 ` [Qemu-arm] [Qemu-devel] [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none" Markus Armbruster
2018-04-26 11:45   ` Markus Armbruster
2018-04-26 15:20   ` [Qemu-arm] " Thomas Huth
2018-04-26 15:20     ` Thomas Huth
2018-04-27  0:32     ` Eduardo Habkost
2018-04-27  0:32       ` Eduardo Habkost
2018-04-27  3:52       ` [Qemu-arm] " Thomas Huth
2018-04-27  3:52         ` Thomas Huth
2018-04-27  6:31       ` [Qemu-arm] " Markus Armbruster
2018-04-27  6:31         ` Markus Armbruster
2018-04-27  7:31         ` [Qemu-arm] " Thomas Huth
2018-04-27  7:31           ` Thomas Huth
2018-04-27  8:05           ` [Qemu-arm] " Markus Armbruster
2018-04-27  8:05             ` Markus Armbruster
2018-05-07 13:53         ` Eduardo Habkost
2018-05-07 13:53           ` Eduardo Habkost
2018-05-07 16:50           ` [Qemu-arm] " Markus Armbruster
2018-05-07 16:50             ` Markus Armbruster
2018-05-07 17:02             ` [Qemu-arm] " Thomas Huth
2018-05-07 17:02               ` Thomas Huth
2018-05-07 17:04             ` [Qemu-arm] " Peter Maydell
2018-05-07 17:04               ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2018-05-07 18:21             ` [Qemu-devel] " Eduardo Habkost
2018-05-07 19:13               ` [Qemu-arm] " Thomas Huth
2018-05-07 19:13                 ` Thomas Huth
2018-05-07 19:32                 ` Eduardo Habkost [this message]
2018-05-07 19:32                   ` Eduardo Habkost
2018-05-08  5:33                   ` [Qemu-arm] [Qemu-devel] Running QEMU without default devices / kernel / bios (was: Test devices with all machines, not only with "none") Thomas Huth
2018-05-08  5:33                     ` Thomas Huth
2018-05-08 10:47                     ` [Qemu-devel] Running QEMU without default devices / kernel / bios Thomas Huth
2018-05-08 10:47                       ` Thomas Huth
2018-05-08 16:40                     ` [Qemu-arm] [Qemu-devel] Running QEMU without default devices / kernel / bios (was: Test devices with all machines, not only with "none") Eduardo Habkost
2018-05-08 16:40                       ` Eduardo Habkost
2018-05-09  7:41                       ` [Qemu-arm] [Qemu-ppc] [Qemu-devel] Running QEMU without default devices / kernel / bios Thomas Huth
2018-05-09  7:41                         ` [Qemu-devel] [Qemu-ppc] " Thomas Huth
2018-05-09 11:36                         ` Markus Armbruster
2018-05-09 11:36                           ` Markus Armbruster
2018-05-08  5:41                   ` [Qemu-arm] [Qemu-devel] [RFC PATCH] tests/device-introspect: Test devices with all machines, not only with "none" Markus Armbruster
2018-05-08  5:41                     ` Markus Armbruster

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=20180507193220.GF25013@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@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.