The tests themselves are the same as the ISA device ones.
Only the main() changes as the "tpm-tis-device" device gets
instantiated. Also the base address of the device is not
0xFED40000 anymore but matches the base address of the
ARM virt platform bus.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
---
tests/qtest/tpm-tis-device-swtpm-test.c | 76 +++++++++++++++++++++
tests/qtest/tpm-tis-device-test.c | 87 +++++++++++++++++++++++++
tests/qtest/Makefile.include | 5 ++
3 files changed, 168 insertions(+)
create mode 100644 tests/qtest/tpm-tis-device-swtpm-test.c
create mode 100644 tests/qtest/tpm-tis-device-test.c
diff --git a/tests/qtest/tpm-tis-device-swtpm-test.c b/tests/qtest/tpm-tis-device-swtpm-test.c
new file mode 100644
index 0000000000..7b20035142
--- /dev/null
+++ b/tests/qtest/tpm-tis-device-swtpm-test.c
@@ -0,0 +1,76 @@
+/*
+ * QTest testcase for Sysbus TPM TIS talking to external swtpm and swtpm
+ * migration
+ *
+ * Copyright (c) 2018 IBM Corporation
+ * with parts borrowed from migration-test.c that is:
+ * Copyright (c) 2016-2018 Red Hat, Inc. and/or its affiliates
+ *
+ * Authors:
+ * Stefan Berger <stefanb@linux.vnet.ibm.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 <glib/gstdio.h>
+
+#include "libqtest.h"
+#include "qemu/module.h"
+#include "tpm-tests.h"
+#include "hw/acpi/tpm.h"
+
+uint64_t tpm_tis_base_addr = 0xc000000;
+#define MACHINE_OPTIONS "-machine virt,gic-version=max -accel tcg"
+
+typedef struct TestState {
+ char *src_tpm_path;
+ char *dst_tpm_path;
+ char *uri;
+} TestState;
+
+static void tpm_tis_swtpm_test(const void *data)
+{
+ const TestState *ts = data;
+
+ tpm_test_swtpm_test(ts->src_tpm_path, tpm_util_tis_transfer,
+ "tpm-tis-device", MACHINE_OPTIONS);
+}
+
+static void tpm_tis_swtpm_migration_test(const void *data)
+{
+ const TestState *ts = data;
+
+ tpm_test_swtpm_migration_test(ts->src_tpm_path, ts->dst_tpm_path, ts->uri,
+ tpm_util_tis_transfer, "tpm-tis-device",
+ MACHINE_OPTIONS);
+}
+
+int main(int argc, char **argv)
+{
+ int ret;
+ TestState ts = { 0 };
+
+ ts.src_tpm_path = g_dir_make_tmp("qemu-tpm-tis-device-swtpm-test.XXXXXX",
+ NULL);
+ ts.dst_tpm_path = g_dir_make_tmp("qemu-tpm-tis-device-swtpm-test.XXXXXX",
+ NULL);
+ ts.uri = g_strdup_printf("unix:%s/migsocket", ts.src_tpm_path);
+
+ module_call_init(MODULE_INIT_QOM);
+ g_test_init(&argc, &argv, NULL);
+
+ qtest_add_data_func("/tpm/tis-swtpm/test", &ts, tpm_tis_swtpm_test);
+ qtest_add_data_func("/tpm/tis-swtpm-migration/test", &ts,
+ tpm_tis_swtpm_migration_test);
+ ret = g_test_run();
+
+ g_rmdir(ts.dst_tpm_path);
+ g_free(ts.dst_tpm_path);
+ g_rmdir(ts.src_tpm_path);
+ g_free(ts.src_tpm_path);
+ g_free(ts.uri);
+
+ return ret;
+}
diff --git a/tests/qtest/tpm-tis-device-test.c b/tests/qtest/tpm-tis-device-test.c
new file mode 100644
index 0000000000..63ed36440f
--- /dev/null
+++ b/tests/qtest/tpm-tis-device-test.c
@@ -0,0 +1,87 @@
+/*
+ * QTest testcase for SYSBUS TPM TIS
+ *
+ * Copyright (c) 2018 Red Hat, Inc.
+ * Copyright (c) 2018 IBM Corporation
+ *
+ * Authors:
+ * Marc-André Lureau <marcandre.lureau@redhat.com>
+ * Stefan Berger <stefanb@linux.vnet.ibm.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 <glib/gstdio.h>
+
+#include "io/channel-socket.h"
+#include "libqtest-single.h"
+#include "qemu/module.h"
+#include "tpm-emu.h"
+#include "tpm-util.h"
+#include "tpm-tis-util.h"
+
+/*
+ * As the Sysbus tpm-tis-device is instantiated on the ARM virt
+ * platform bus and it is the only sysbus device dynamically
+ * instantiated, it gets plugged at its base address
+ */
+uint64_t tpm_tis_base_addr = 0xc000000;
+
+int main(int argc, char **argv)
+{
+ char *tmp_path = g_dir_make_tmp("qemu-tpm-tis-device-test.XXXXXX", NULL);
+ GThread *thread;
+ TestState test;
+ char *args;
+ int ret;
+
+ module_call_init(MODULE_INIT_QOM);
+ g_test_init(&argc, &argv, NULL);
+
+ test.addr = g_new0(SocketAddress, 1);
+ test.addr->type = SOCKET_ADDRESS_TYPE_UNIX;
+ test.addr->u.q_unix.path = g_build_filename(tmp_path, "sock", NULL);
+ g_mutex_init(&test.data_mutex);
+ g_cond_init(&test.data_cond);
+ test.data_cond_signal = false;
+
+ thread = g_thread_new(NULL, tpm_emu_ctrl_thread, &test);
+ tpm_emu_test_wait_cond(&test);
+
+ args = g_strdup_printf(
+ "-machine virt,gic-version=max -accel tcg "
+ "-chardev socket,id=chr,path=%s "
+ "-tpmdev emulator,id=dev,chardev=chr "
+ "-device tpm-tis-device,tpmdev=dev",
+ test.addr->u.q_unix.path);
+ qtest_start(args);
+
+ qtest_add_data_func("/tpm-tis/test_check_localities", &test,
+ tpm_tis_test_check_localities);
+
+ qtest_add_data_func("/tpm-tis/test_check_access_reg", &test,
+ tpm_tis_test_check_access_reg);
+
+ qtest_add_data_func("/tpm-tis/test_check_access_reg_seize", &test,
+ tpm_tis_test_check_access_reg_seize);
+
+ qtest_add_data_func("/tpm-tis/test_check_access_reg_release", &test,
+ tpm_tis_test_check_access_reg_release);
+
+ qtest_add_data_func("/tpm-tis/test_check_transmit", &test,
+ tpm_tis_test_check_transmit);
+
+ ret = g_test_run();
+
+ qtest_end();
+
+ g_thread_join(thread);
+ g_unlink(test.addr->u.q_unix.path);
+ qapi_free_SocketAddress(test.addr);
+ g_rmdir(tmp_path);
+ g_free(tmp_path);
+ g_free(args);
+ return ret;
+}
diff --git a/tests/qtest/Makefile.include b/tests/qtest/Makefile.include
index 44aac68b25..383b0ab217 100644
--- a/tests/qtest/Makefile.include
+++ b/tests/qtest/Makefile.include
@@ -130,6 +130,8 @@ check-qtest-arm-y += hexloader-test
check-qtest-arm-$(CONFIG_PFLASH_CFI02) += pflash-cfi02-test
check-qtest-aarch64-y += arm-cpu-features
+check-qtest-aarch64-$(CONFIG_TPM_TIS_SYSBUS) += tpm-tis-device-test
+check-qtest-aarch64-$(CONFIG_TPM_TIS_SYSBUS) += tpm-tis-device-swtpm-test
check-qtest-aarch64-y += numa-test
check-qtest-aarch64-y += boot-serial-test
check-qtest-aarch64-y += migration-test
@@ -302,7 +304,10 @@ tests/qtest/tpm-crb-swtpm-test$(EXESUF): tests/qtest/tpm-crb-swtpm-test.o tests/
tests/qtest/tpm-crb-test$(EXESUF): tests/qtest/tpm-crb-test.o tests/qtest/tpm-emu.o $(test-io-obj-y)
tests/qtest/tpm-tis-swtpm-test$(EXESUF): tests/qtest/tpm-tis-swtpm-test.o tests/qtest/tpm-emu.o \
tests/qtest/tpm-util.o tests/qtest/tpm-tests.o $(test-io-obj-y)
+tests/qtest/tpm-tis-device-swtpm-test$(EXESUF): tests/qtest/tpm-tis-device-swtpm-test.o tests/qtest/tpm-emu.o \
+ tests/qtest/tpm-util.o tests/qtest/tpm-tests.o $(test-io-obj-y)
tests/qtest/tpm-tis-test$(EXESUF): tests/qtest/tpm-tis-test.o tests/qtest/tpm-tis-util.o tests/qtest/tpm-emu.o $(test-io-obj-y)
+tests/qtest/tpm-tis-device-test$(EXESUF): tests/qtest/tpm-tis-device-test.o tests/qtest/tpm-tis-util.o tests/qtest/tpm-emu.o $(test-io-obj-y)
# QTest rules
--
2.20.1
On Thu, 5 Mar 2020 at 16:52, Eric Auger <eric.auger@redhat.com> wrote: > > The tests themselves are the same as the ISA device ones. > Only the main() changes as the "tpm-tis-device" device gets > instantiated. Also the base address of the device is not > 0xFED40000 anymore but matches the base address of the > ARM virt platform bus. > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Hi Eric; the commit adding this test is from back in 2020, but I've just noticed something a bit odd about it: > + args = g_strdup_printf( > + "-machine virt,gic-version=max -accel tcg " > + "-chardev socket,id=chr,path=%s " > + "-tpmdev emulator,id=dev,chardev=chr " > + "-device tpm-tis-device,tpmdev=dev", > + test.addr->u.q_unix.path); This 'virt' command line doesn't specify a CPU type, so it will end up running with a Cortex-A15 (32-bit). Was that intended? Also, it will get a GICv3, which is a definitely odd combination with an A15, which was a GICv2 CPU... I noticed this because I have some recent GICv3 patches which end up asserting if the GICv3 and a non-GICv3 CPU are used together, and this test case triggers them. Since the user can also cause an assert with that kind of command line I'm going to rework them (either to make the virt board fail cleanly or else to make the GICv3 code do something plausible even if the real hardware CPU nominally didn't have a GICv3). But maybe we should make this test case not use a non-standard combination anyway? (The meson conversion seems to have resulted in this test being run under qemu-system-arm as well, incidentally, so I guess we would want it to specify either 'a 64 bit CPU and GICv3' or 'a 32 bit CPU and GICv2' accordingly. Or limit the test to aarch64...) thanks -- PMM
Hi Peter, On 5/12/22 15:08, Peter Maydell wrote: > On Thu, 5 Mar 2020 at 16:52, Eric Auger <eric.auger@redhat.com> wrote: >> The tests themselves are the same as the ISA device ones. >> Only the main() changes as the "tpm-tis-device" device gets >> instantiated. Also the base address of the device is not >> 0xFED40000 anymore but matches the base address of the >> ARM virt platform bus. >> >> Signed-off-by: Eric Auger <eric.auger@redhat.com> >> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > Hi Eric; the commit adding this test is from back in 2020, but I've > just noticed something a bit odd about it: > >> + args = g_strdup_printf( >> + "-machine virt,gic-version=max -accel tcg " >> + "-chardev socket,id=chr,path=%s " >> + "-tpmdev emulator,id=dev,chardev=chr " >> + "-device tpm-tis-device,tpmdev=dev", >> + test.addr->u.q_unix.path); > This 'virt' command line doesn't specify a CPU type, so it > will end up running with a Cortex-A15 (32-bit). Was > that intended? Also, it will get a GICv3, which is a > definitely odd combination with an A15, which was a GICv2 CPU... no it is not intended. I guess it should include "-cpu max" too as arm-cpu-features.c does? > > I noticed this because I have some recent GICv3 patches which > end up asserting if the GICv3 and a non-GICv3 CPU are used together, > and this test case triggers them. Since the user can also cause > an assert with that kind of command line I'm going to rework them > (either to make the virt board fail cleanly or else to make the > GICv3 code do something plausible even if the real hardware CPU > nominally didn't have a GICv3). But maybe we should make this > test case not use a non-standard combination anyway? (The meson > conversion seems to have resulted in this test being run under > qemu-system-arm as well, incidentally, so I guess we would want > it to specify either 'a 64 bit CPU and GICv3' or 'a 32 bit > CPU and GICv2' accordingly. Or limit the test to aarch64...) limiting the test to aarch64 may be enough? Eric > > thanks > -- PMM >
On Thu, 12 May 2022 at 16:59, Eric Auger <eric.auger@redhat.com> wrote: > > Hi Peter, > > On 5/12/22 15:08, Peter Maydell wrote: > > On Thu, 5 Mar 2020 at 16:52, Eric Auger <eric.auger@redhat.com> wrote: > >> The tests themselves are the same as the ISA device ones. > >> Only the main() changes as the "tpm-tis-device" device gets > >> instantiated. Also the base address of the device is not > >> 0xFED40000 anymore but matches the base address of the > >> ARM virt platform bus. > >> > >> Signed-off-by: Eric Auger <eric.auger@redhat.com> > >> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > > Hi Eric; the commit adding this test is from back in 2020, but I've > > just noticed something a bit odd about it: > > > >> + args = g_strdup_printf( > >> + "-machine virt,gic-version=max -accel tcg " > >> + "-chardev socket,id=chr,path=%s " > >> + "-tpmdev emulator,id=dev,chardev=chr " > >> + "-device tpm-tis-device,tpmdev=dev", > >> + test.addr->u.q_unix.path); > > This 'virt' command line doesn't specify a CPU type, so it > > will end up running with a Cortex-A15 (32-bit). Was > > that intended? Also, it will get a GICv3, which is a > > definitely odd combination with an A15, which was a GICv2 CPU... > no it is not intended. I guess it should include "-cpu max" too > as arm-cpu-features.c does? Seems like a reasonable thing to set, yes. > > I noticed this because I have some recent GICv3 patches which > > end up asserting if the GICv3 and a non-GICv3 CPU are used together, > > and this test case triggers them. Since the user can also cause > > an assert with that kind of command line I'm going to rework them > > (either to make the virt board fail cleanly or else to make the > > GICv3 code do something plausible even if the real hardware CPU > > nominally didn't have a GICv3). But maybe we should make this > > test case not use a non-standard combination anyway? (The meson > > conversion seems to have resulted in this test being run under > > qemu-system-arm as well, incidentally, so I guess we would want > > it to specify either 'a 64 bit CPU and GICv3' or 'a 32 bit > > CPU and GICv2' accordingly. Or limit the test to aarch64...) > limiting the test to aarch64 may be enough? Mmm, if running the test under 'qemu-system-arm' isn't giving us interesting extra coverage we might as well save the CI cycles. -- PMM
On Thu, 12 May 2022 17:05:41 +0100 Peter Maydell <peter.maydell@linaro.org> wrote: > On Thu, 12 May 2022 at 16:59, Eric Auger <eric.auger@redhat.com> wrote: > > > > Hi Peter, > > > > On 5/12/22 15:08, Peter Maydell wrote: > > > On Thu, 5 Mar 2020 at 16:52, Eric Auger <eric.auger@redhat.com> wrote: > > >> The tests themselves are the same as the ISA device ones. > > >> Only the main() changes as the "tpm-tis-device" device gets > > >> instantiated. Also the base address of the device is not > > >> 0xFED40000 anymore but matches the base address of the > > >> ARM virt platform bus. > > >> > > >> Signed-off-by: Eric Auger <eric.auger@redhat.com> > > >> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > > > Hi Eric; the commit adding this test is from back in 2020, but I've > > > just noticed something a bit odd about it: > > > > > >> + args = g_strdup_printf( > > >> + "-machine virt,gic-version=max -accel tcg " > > >> + "-chardev socket,id=chr,path=%s " > > >> + "-tpmdev emulator,id=dev,chardev=chr " > > >> + "-device tpm-tis-device,tpmdev=dev", > > >> + test.addr->u.q_unix.path); > > > This 'virt' command line doesn't specify a CPU type, so it > > > will end up running with a Cortex-A15 (32-bit). Was > > > that intended? Also, it will get a GICv3, which is a > > > definitely odd combination with an A15, which was a GICv2 CPU... > > no it is not intended. I guess it should include "-cpu max" too > > as arm-cpu-features.c does? > > Seems like a reasonable thing to set, yes. > > > > I noticed this because I have some recent GICv3 patches which > > > end up asserting if the GICv3 and a non-GICv3 CPU are used together, > > > and this test case triggers them. Since the user can also cause > > > an assert with that kind of command line I'm going to rework them > > > (either to make the virt board fail cleanly or else to make the > > > GICv3 code do something plausible even if the real hardware CPU > > > nominally didn't have a GICv3). But maybe we should make this > > > test case not use a non-standard combination anyway? (The meson > > > conversion seems to have resulted in this test being run under > > > qemu-system-arm as well, incidentally, so I guess we would want > > > it to specify either 'a 64 bit CPU and GICv3' or 'a 32 bit > > > CPU and GICv2' accordingly. Or limit the test to aarch64...) > > limiting the test to aarch64 may be enough? > > Mmm, if running the test under 'qemu-system-arm' isn't giving > us interesting extra coverage we might as well save the CI cycles. agreed, we probably should limit all ARM tests in bios-tables-test to aarch64 'qemu-system-arm' doesn't give us anything extra on top of what aarch64 already does. > > -- PMM >
© 2016 - 2025 Red Hat, Inc.