From: Laszlo Ersek <lersek@redhat.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH v3 2/4] i440fx-test: give each GTest case its own qtest
Date: Fri, 29 Nov 2013 18:12:20 +0100 [thread overview]
Message-ID: <1385745142-20520-3-git-send-email-lersek@redhat.com> (raw)
In-Reply-To: <1385745142-20520-1-git-send-email-lersek@redhat.com>
The current two GTest cases, /i440fx/defaults and /i440fx/pam can share a
qemu process, but the next two cases will need dedicated instances. It is
messy (and order-dependent) to dynamically configure GTest cases one by
one to start, stop, or keep the current qtest (*); let's just have each
GTest work with its own qtest. The performance difference should be
negligible.
(*) As g_test_run() can be invoked at most once per process startup, and
it runs GTest cases in sequence, we'd need clumsy data structures to
control each GTest case to start/stop/keep the qemu instance. Or, we'd
have to code the same information into the test methods themselves, which
would make them even more order-dependent.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
tests/i440fx-test.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/tests/i440fx-test.c b/tests/i440fx-test.c
index 6ac46bf..3962bca 100644
--- a/tests/i440fx-test.c
+++ b/tests/i440fx-test.c
@@ -28,16 +28,27 @@
typedef struct TestData
{
int num_cpus;
- QPCIBus *bus;
} TestData;
+static QPCIBus *test_start_get_bus(const TestData *s)
+{
+ char *cmdline;
+
+ cmdline = g_strdup_printf("-smp %d", s->num_cpus);
+ qtest_start(cmdline);
+ g_free(cmdline);
+ return qpci_init_pc();
+}
+
static void test_i440fx_defaults(gconstpointer opaque)
{
const TestData *s = opaque;
+ QPCIBus *bus;
QPCIDevice *dev;
uint32_t value;
- dev = qpci_device_find(s->bus, QPCI_DEVFN(0, 0));
+ bus = test_start_get_bus(s);
+ dev = qpci_device_find(bus, QPCI_DEVFN(0, 0));
g_assert(dev != NULL);
/* 3.2.2 */
@@ -121,6 +132,8 @@ static void test_i440fx_defaults(gconstpointer opaque)
g_assert_cmpint(qpci_config_readb(dev, 0x91), ==, 0x00); /* ERRSTS */
/* 3.2.26 */
g_assert_cmpint(qpci_config_readb(dev, 0x93), ==, 0x00); /* TRC */
+
+ qtest_end();
}
#define PAM_RE 1
@@ -179,6 +192,7 @@ static void write_area(uint32_t start, uint32_t end, uint8_t value)
static void test_i440fx_pam(gconstpointer opaque)
{
const TestData *s = opaque;
+ QPCIBus *bus;
QPCIDevice *dev;
int i;
static struct {
@@ -201,7 +215,8 @@ static void test_i440fx_pam(gconstpointer opaque)
{ 0xEC000, 0xEFFFF }, /* BIOS Extension */
};
- dev = qpci_device_find(s->bus, QPCI_DEVFN(0, 0));
+ bus = test_start_get_bus(s);
+ dev = qpci_device_find(bus, QPCI_DEVFN(0, 0));
g_assert(dev != NULL);
for (i = 0; i < ARRAY_SIZE(pam_area); i++) {
@@ -254,30 +269,21 @@ static void test_i440fx_pam(gconstpointer opaque)
/* Verify the area is not our new mask */
g_assert(!verify_area(pam_area[i].start, pam_area[i].end, 0x82));
}
+ qtest_end();
}
int main(int argc, char **argv)
{
TestData data;
- char *cmdline;
int ret;
g_test_init(&argc, &argv, NULL);
data.num_cpus = 1;
- cmdline = g_strdup_printf("-smp %d", data.num_cpus);
- qtest_start(cmdline);
- g_free(cmdline);
-
- data.bus = qpci_init_pc();
-
g_test_add_data_func("/i440fx/defaults", &data, test_i440fx_defaults);
g_test_add_data_func("/i440fx/pam", &data, test_i440fx_pam);
ret = g_test_run();
-
- qtest_end();
-
return ret;
}
--
1.8.3.1
next prev parent reply other threads:[~2013-11-29 17:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-29 17:12 [Qemu-devel] [PATCH v3 0/4] i440fx-test: check firmware visibility Laszlo Ersek
2013-11-29 17:12 ` [Qemu-devel] [PATCH v3 1/4] i440fx-test: qtest_start() should be paired with qtest_end() Laszlo Ersek
2013-11-29 17:12 ` Laszlo Ersek [this message]
2013-11-29 17:12 ` [Qemu-devel] [PATCH v3 3/4] i440fx-test: generate temporary firmware blob Laszlo Ersek
2013-11-29 17:12 ` [Qemu-devel] [PATCH v3 4/4] i440fx-test: verify firmware under 4G and 1M, both -bios and -pflash Laszlo Ersek
2013-12-09 17:53 ` [Qemu-devel] [PATCH v3 0/4] i440fx-test: check firmware visibility Paolo Bonzini
2013-12-16 16:16 ` Michael S. Tsirkin
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=1385745142-20520-3-git-send-email-lersek@redhat.com \
--to=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).