System tests on x86 use isa-debug-exit device in order to signal
success or failure to the test runner. Unfortunately it's not easily
usable on other architectures, since a guest needs to access
address_space_io, which may not be as straightforward as on x86.
Also, it requires adding ISA bus, which an architecture might not
otherwise need.
Introduce mmio-debug-exit device, which has the same semantics, but is
triggered by writes to memory.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
hw/misc/Kconfig | 3 ++
hw/misc/debugexit_mmio.c | 80 ++++++++++++++++++++++++++++++++++++++++
hw/misc/meson.build | 1 +
hw/s390x/Kconfig | 1 +
4 files changed, 85 insertions(+)
create mode 100644 hw/misc/debugexit_mmio.c
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index cbabe9f78c..0f12735ef7 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -15,6 +15,9 @@ config ISA_DEBUG
bool
depends on ISA_BUS
+config MMIO_DEBUGEXIT
+ bool
+
config SGA
bool
depends on ISA_BUS
diff --git a/hw/misc/debugexit_mmio.c b/hw/misc/debugexit_mmio.c
new file mode 100644
index 0000000000..5e823cc01c
--- /dev/null
+++ b/hw/misc/debugexit_mmio.c
@@ -0,0 +1,80 @@
+/*
+ * Exit with status X when the guest writes X (little-endian) to a specified
+ * address. For testing purposes only.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "exec/address-spaces.h"
+#include "exec/memory.h"
+#include "hw/qdev-core.h"
+#include "hw/qdev-properties.h"
+
+#define TYPE_MMIO_DEBUG_EXIT_DEVICE "mmio-debug-exit"
+OBJECT_DECLARE_SIMPLE_TYPE(MMIODebugExitState, MMIO_DEBUG_EXIT_DEVICE)
+
+struct MMIODebugExitState {
+ DeviceState parent_obj;
+
+ uint32_t base;
+ uint32_t size;
+ MemoryRegion region;
+};
+
+static uint64_t mmio_debug_exit_read(void *opaque, hwaddr addr, unsigned size)
+{
+ return 0;
+}
+
+static void mmio_debug_exit_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned width)
+{
+ exit(val);
+}
+
+static const MemoryRegionOps mmio_debug_exit_ops = {
+ .read = mmio_debug_exit_read,
+ .write = mmio_debug_exit_write,
+ .valid.min_access_size = 1,
+ .valid.max_access_size = 8,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void mmio_debug_exit_realizefn(DeviceState *d, Error **errp)
+{
+ MMIODebugExitState *s = MMIO_DEBUG_EXIT_DEVICE(d);
+
+ memory_region_init_io(&s->region, OBJECT(s), &mmio_debug_exit_ops, s,
+ TYPE_MMIO_DEBUG_EXIT_DEVICE, s->size);
+ memory_region_add_subregion(get_system_memory(), s->base, &s->region);
+}
+
+static Property mmio_debug_exit_properties[] = {
+ DEFINE_PROP_UINT32("base", MMIODebugExitState, base, 0),
+ DEFINE_PROP_UINT32("size", MMIODebugExitState, size, 1),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void mmio_debug_exit_class_initfn(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+
+ dc->realize = mmio_debug_exit_realizefn;
+ device_class_set_props(dc, mmio_debug_exit_properties);
+ set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static const TypeInfo mmio_debug_exit_info = {
+ .name = TYPE_MMIO_DEBUG_EXIT_DEVICE,
+ .parent = TYPE_DEVICE,
+ .instance_size = sizeof(MMIODebugExitState),
+ .class_init = mmio_debug_exit_class_initfn,
+};
+
+static void mmio_debug_exit_register_types(void)
+{
+ type_register_static(&mmio_debug_exit_info);
+}
+
+type_init(mmio_debug_exit_register_types)
diff --git a/hw/misc/meson.build b/hw/misc/meson.build
index 95268eddc0..1d2a1067dc 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -2,6 +2,7 @@ softmmu_ss.add(when: 'CONFIG_APPLESMC', if_true: files('applesmc.c'))
softmmu_ss.add(when: 'CONFIG_EDU', if_true: files('edu.c'))
softmmu_ss.add(when: 'CONFIG_FW_CFG_DMA', if_true: files('vmcoreinfo.c'))
softmmu_ss.add(when: 'CONFIG_ISA_DEBUG', if_true: files('debugexit.c'))
+softmmu_ss.add(when: 'CONFIG_MMIO_DEBUGEXIT', if_true: files('debugexit_mmio.c'))
softmmu_ss.add(when: 'CONFIG_ISA_TESTDEV', if_true: files('pc-testdev.c'))
softmmu_ss.add(when: 'CONFIG_PCA9552', if_true: files('pca9552.c'))
softmmu_ss.add(when: 'CONFIG_PCI_TESTDEV', if_true: files('pci-testdev.c'))
diff --git a/hw/s390x/Kconfig b/hw/s390x/Kconfig
index 5e7d8a2bae..9223715dcc 100644
--- a/hw/s390x/Kconfig
+++ b/hw/s390x/Kconfig
@@ -5,6 +5,7 @@ config S390_CCW_VIRTIO
imply VFIO_AP
imply VFIO_CCW
imply WDT_DIAG288
+ imply MMIO_DEBUGEXIT
select PCI
select S390_FLIC
select SCLPCONSOLE
--
2.35.3On 7/12/22 00:26, Ilya Leoshkevich wrote: > System tests on x86 use isa-debug-exit device in order to signal > success or failure to the test runner. Unfortunately it's not easily > usable on other architectures, since a guest needs to access > address_space_io, which may not be as straightforward as on x86. > Also, it requires adding ISA bus, which an architecture might not > otherwise need. > > Introduce mmio-debug-exit device, which has the same semantics, but is > triggered by writes to memory. > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> You shouldn't need this for s390x, as there are already (at least) two other paths to qemu_system_shutdown_request. E.g. SIGP, which has a stop option. r~
On Tue, 2022-07-12 at 10:42 +0530, Richard Henderson wrote:
> On 7/12/22 00:26, Ilya Leoshkevich wrote:
> > System tests on x86 use isa-debug-exit device in order to signal
> > success or failure to the test runner. Unfortunately it's not
> > easily
> > usable on other architectures, since a guest needs to access
> > address_space_io, which may not be as straightforward as on x86.
> > Also, it requires adding ISA bus, which an architecture might not
> > otherwise need.
> >
> > Introduce mmio-debug-exit device, which has the same semantics, but
> > is
> > triggered by writes to memory.
> >
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
> You shouldn't need this for s390x, as there are already (at least)
> two other paths to
> qemu_system_shutdown_request.
>
> E.g. SIGP, which has a stop option.
>
>
> r~
>
I would normally use lpswe + disabled wait, but this always gives me
exit status code 0, which doesn't allow easily distinguishing between
success and failure.
Code-wise SIGP seems to do roughly the same thing, and a quick
experiment with:
lgfi %r4,-1
lgfi %r5,-1
larl %r6,_cpuaddr
stap 0(%r6)
lh %r6,0(%r6)
nilh %r6,0
sigp %r4,%r6,5
_cpuaddr: .short 0
confirmed that we get exit status code 0 as well.
Best regards,
Ilya
On 12.07.22 11:52, Ilya Leoshkevich wrote: > On Tue, 2022-07-12 at 10:42 +0530, Richard Henderson wrote: >> On 7/12/22 00:26, Ilya Leoshkevich wrote: >>> System tests on x86 use isa-debug-exit device in order to signal >>> success or failure to the test runner. Unfortunately it's not >>> easily >>> usable on other architectures, since a guest needs to access >>> address_space_io, which may not be as straightforward as on x86. >>> Also, it requires adding ISA bus, which an architecture might not >>> otherwise need. >>> >>> Introduce mmio-debug-exit device, which has the same semantics, but >>> is >>> triggered by writes to memory. >>> >>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> >> >> You shouldn't need this for s390x, as there are already (at least) >> two other paths to >> qemu_system_shutdown_request. >> >> E.g. SIGP, which has a stop option. >> >> >> r~ >> > > I would normally use lpswe + disabled wait, but this always gives me > exit status code 0, which doesn't allow easily distinguishing between > success and failure. > > Code-wise SIGP seems to do roughly the same thing, and a quick > experiment with: > > lgfi %r4,-1 > lgfi %r5,-1 > larl %r6,_cpuaddr > stap 0(%r6) > lh %r6,0(%r6) > nilh %r6,0 > sigp %r4,%r6,5 > _cpuaddr: .short 0 > > confirmed that we get exit status code 0 as well. disabled wait should trigger a qemu_system_guest_panicked(). But "panic_action == PANIC_ACTION_SHUTDOWN" seems to only make qemu_main_loop() return with main_loop_should_exit() == true. main/qemu_main will always return 0. We could return != 0 on guest panic, but not sure if that could break existing scripts. We'd need a new QEMU toggle for that most probably ... -- Thanks, David / dhildenb
On 12.07.22 11:52, Ilya Leoshkevich wrote: > On Tue, 2022-07-12 at 10:42 +0530, Richard Henderson wrote: >> On 7/12/22 00:26, Ilya Leoshkevich wrote: >>> System tests on x86 use isa-debug-exit device in order to signal >>> success or failure to the test runner. Unfortunately it's not >>> easily >>> usable on other architectures, since a guest needs to access >>> address_space_io, which may not be as straightforward as on x86. >>> Also, it requires adding ISA bus, which an architecture might not >>> otherwise need. >>> >>> Introduce mmio-debug-exit device, which has the same semantics, but >>> is >>> triggered by writes to memory. >>> >>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> >> >> You shouldn't need this for s390x, as there are already (at least) >> two other paths to >> qemu_system_shutdown_request. >> >> E.g. SIGP, which has a stop option. >> >> >> r~ >> > > I would normally use lpswe + disabled wait, but this always gives me > exit status code 0, which doesn't allow easily distinguishing between > success and failure. > > Code-wise SIGP seems to do roughly the same thing, and a quick > experiment with: > > lgfi %r4,-1 > lgfi %r5,-1 > larl %r6,_cpuaddr > stap 0(%r6) > lh %r6,0(%r6) > nilh %r6,0 > sigp %r4,%r6,5 > _cpuaddr: .short 0 > > confirmed that we get exit status code 0 as well. disabled wait should trigger a qemu_system_guest_panicked(). But "panic_action == PANIC_ACTION_SHUTDOWN" seems to only make qemu_main_loop() return with main_loop_should_exit() == true. main/qemu_main will always return 0. We could return != 0 on guest panic, but not sure if that could break existing scripts. We'd need a new QEMU toggle for that most probably ... -- Thanks, David / dhildenb
On Tue, 2022-07-12 at 12:08 +0200, David Hildenbrand wrote: > On 12.07.22 11:52, Ilya Leoshkevich wrote: > > On Tue, 2022-07-12 at 10:42 +0530, Richard Henderson wrote: > > > On 7/12/22 00:26, Ilya Leoshkevich wrote: > > > > System tests on x86 use isa-debug-exit device in order to > > > > signal > > > > success or failure to the test runner. Unfortunately it's not > > > > easily > > > > usable on other architectures, since a guest needs to access > > > > address_space_io, which may not be as straightforward as on > > > > x86. > > > > Also, it requires adding ISA bus, which an architecture might > > > > not > > > > otherwise need. > > > > > > > > Introduce mmio-debug-exit device, which has the same semantics, > > > > but > > > > is > > > > triggered by writes to memory. > > > > > > > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > > > > > > You shouldn't need this for s390x, as there are already (at > > > least) > > > two other paths to > > > qemu_system_shutdown_request. > > > > > > E.g. SIGP, which has a stop option. > > > > > > > > > r~ > > > > > > > I would normally use lpswe + disabled wait, but this always gives > > me > > exit status code 0, which doesn't allow easily distinguishing > > between > > success and failure. > > > > Code-wise SIGP seems to do roughly the same thing, and a quick > > experiment with: > > > > lgfi %r4,-1 > > lgfi %r5,-1 > > larl %r6,_cpuaddr > > stap 0(%r6) > > lh %r6,0(%r6) > > nilh %r6,0 > > sigp %r4,%r6,5 > > _cpuaddr: .short 0 > > > > confirmed that we get exit status code 0 as well. > > disabled wait should trigger a qemu_system_guest_panicked(). > > But "panic_action == PANIC_ACTION_SHUTDOWN" seems to only make > qemu_main_loop() return with main_loop_should_exit() == true. > > main/qemu_main will always return 0. > > We could return != 0 on guest panic, but not sure if that could break > existing scripts. We'd need a new QEMU toggle for that most probably > ... > I wonder if a device is a cleaner way to solve this? It may be used on all architectures, so there is no need to invent per-architecture way to exit with a specific code. Maybe we can even replace Intel's debugexit with it.
© 2016 - 2026 Red Hat, Inc.