From: Thomas Huth <thuth@redhat.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>,
Collin Walling <walling@linux.ibm.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>, Greg Kurz <groug@kaod.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v1] tests: Add a simple device_del test for PCI devices
Date: Fri, 15 Feb 2019 10:05:53 +0100 [thread overview]
Message-ID: <e3a0a9ed-3edb-80a2-8ccd-ff0ed189d304@redhat.com> (raw)
In-Reply-To: <20190214171128.24093-1-david@redhat.com>
On 14/02/2019 18.11, David Hildenbrand wrote:
> The issue with testing asynchronous unplug requests it that they usually
> require a running guest to handle the request. However, to test if
> unplug of PCI devices works, we can apply a nice little trick on some
> architectures:
>
> On system reset, x86 ACPI, s390x and spapr will perform the unplug,
> resulting in the device of interest to get deleted and a DEVICE_DELETED
> event getting sent.
Good idea, and thanks for writing the test! Some comments below...
> diff --git a/tests/device_del-test.c b/tests/device_del-test.c
> new file mode 100644
> index 0000000000..cbc3e78e56
> --- /dev/null
> +++ b/tests/device_del-test.c
> @@ -0,0 +1,103 @@
> +/*
> + * QEMU device_del handling
> + *
> + * Copyright (C) 2019 Red Hat Inc.
> + *
> + * Authors:
> + * David Hildenbrand <david@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "libqtest.h"
> +#include "qapi/qmp/qdict.h"
> +#include "qapi/qmp/qstring.h"
> +
> +static void device_del_request(const char *id)
> +{
> + QDict *resp;
> +
> + resp = qmp("{'execute': 'device_del', 'arguments': { 'id': %s } }", id);
> + g_assert(qdict_haskey(resp, "return"));
> + qobject_unref(resp);
> +}
> +
> +static void system_reset(void)
> +{
> + QDict *resp;
> +
> + resp = qmp("{'execute': 'system_reset'}");
> + g_assert(qdict_haskey(resp, "return"));
> + qobject_unref(resp);
> +}
> +
> +static void wait_device_deleted_event(const char *id)
> +{
> + QDict *resp, *data;
> + QObject *device;
> + QString *qstr;
> +
> + /*
> + * Other devices might get removed along with the removed device. Skip
> + * these.
> + */
> + for (;;) {
> + resp = qtest_qmp_eventwait_ref(global_qtest, "DEVICE_DELETED");
Please avoid global_qtest in new code. We should get rid of that global
variable in the long run - it causes trouble each time we want to re-use
code in tests with multiple test instances.
> + data = qdict_get_qdict(resp, "data");
> + if (!data) {
> + qobject_unref(resp);
> + continue;
> + }
> + device = qdict_get(data, "device");
> + if (!device) {
> + qobject_unref(resp);
> + continue;
> + }
> + qstr = qobject_to(QString, device);
> + g_assert(qstr);
> + if (!strcmp(qstring_get_str(qstr), id)) {
> + qobject_unref(data);
> + qobject_unref(resp);
> + break;
> + }
> + qobject_unref(data);
> + qobject_unref(resp);
> + }
> +}
> +
> +static void test_pci_device_del_request(void)
> +{
> + char *args;
> +
> + args = g_strdup_printf("-device virtio-mouse-pci,id=dev0");
> + qtest_start(args);
Please use qtest_initf() instead and pass its return value to
wait_device_deleted_event(), so you can use it there instead of
global_qtest.
Also there is no need for the g_strdup_printf() here - simply pass the
string directly to the qtest_initf function.
> + /*
> + * Request device removal. As the guest is not running, the request won't
> + * be processed. However during system reset, the removal will be
> + * handled, removing the device.
> + */
> + device_del_request("dev0");
> + system_reset();
> + wait_device_deleted_event("dev0");
> +
> + qtest_end();
> + g_free(args);
> +}
> +
> +int main(int argc, char **argv)
> +{
> + g_test_init(&argc, &argv, NULL);
> +
> + /*
> + * We need a system that will process unplug requests during system resets
> + * and does not do PCI surprise removal. This holds for x86 ACPI,
> + * s390x and spapr.
> + */
> + qtest_add_func("/device_del/pci_device_del_request",
> + test_pci_device_del_request);
> +
> + return g_test_run();
> +}
When you respin, could you maybe also rename the file to
device-plug-test.c instead? ... I still have got some plans for some
device_add tests, that would likely also be a good fit here...
Thomas
next prev parent reply other threads:[~2019-02-15 9:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 17:11 [Qemu-devel] [PATCH v1] tests: Add a simple device_del test for PCI devices David Hildenbrand
2019-02-15 4:10 ` David Gibson
2019-02-15 9:05 ` Thomas Huth [this message]
2019-02-15 9:07 ` Greg Kurz
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=e3a0a9ed-3edb-80a2-8ccd-ff0ed189d304@redhat.com \
--to=thuth@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=ehabkost@redhat.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=walling@linux.ibm.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).