* [PATCH 1/6] hw/misc/ivshmem: Add ivshmem-flat device
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-22 22:22 ` [PATCH 2/6] hw/misc/ivshmem-flat: Allow device to wire itself on sysbus Gustavo Romero
` (5 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
Add a new device, ivshmem-flat, which is similar to the ivshmem PCI but
does not require a PCI bus. It's meant to be used on machines like those
with Cortex-M MCUs, which usually lack a PCI/PCIe bus, e.g. lm3s6965evb
and mps2-an385.
The device currently only supports the sysbus bus.
The new device, just like the ivshmem PCI device, supports both peer
notification via hardware interrupts and shared memory.
The device shared memory size can be set using the 'shmem-size' option
and it defaults to 4 MiB, which is the default size of shmem allocated
by the ivshmem server.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1134
Message-ID: <20231127052024.435743-2-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
docs/system/devices/ivshmem-flat.rst | 33 ++
hw/misc/Kconfig | 5 +
hw/misc/ivshmem-flat.c | 463 +++++++++++++++++++++++++++
hw/misc/meson.build | 2 +
hw/misc/trace-events | 17 +
include/hw/misc/ivshmem-flat.h | 85 +++++
6 files changed, 605 insertions(+)
create mode 100644 docs/system/devices/ivshmem-flat.rst
create mode 100644 hw/misc/ivshmem-flat.c
create mode 100644 include/hw/misc/ivshmem-flat.h
diff --git a/docs/system/devices/ivshmem-flat.rst b/docs/system/devices/ivshmem-flat.rst
new file mode 100644
index 0000000000..1f97052804
--- /dev/null
+++ b/docs/system/devices/ivshmem-flat.rst
@@ -0,0 +1,33 @@
+Inter-VM Shared Memory Flat Device
+----------------------------------
+
+The ivshmem-flat device is meant to be used on machines that lack a PCI bus,
+making them unsuitable for the use of the traditional ivshmem device modeled as
+a PCI device. Machines like those with a Cortex-M MCU are good candidates to use
+the ivshmem-flat device. Also, since the flat version maps the control and
+status registers directly to the memory, it requires a quite tiny "device
+driver" to interact with other VMs, which is useful in some RTOSes, like
+Zephyr, which usually run on constrained resource targets.
+
+Similar to the ivshmem device, the ivshmem-flat device supports both peer
+notification via HW interrupts and Inter-VM shared memory. This allows the
+device to be used together with the traditional ivshmem, enabling communication
+between, for instance, an aarch64 VM (using the traditional ivshmem device and
+running Linux), and an arm VM (using the ivshmem-flat device and running Zephyr
+instead).
+
+The ivshmem-flat device does not support the use of a ``memdev`` option (see
+ivshmem.rst for more details). It relies on the ivshmem server to create and
+distribute the proper shared memory file descriptor and the eventfd(s) to notify
+(interrupt) the peers. Therefore, to use this device, it is always necessary to
+have an ivshmem server up and running for proper device creation.
+
+Although the ivshmem-flat supports both peer notification (interrupts) and
+shared memory, the interrupt mechanism is optional. If no input IRQ is
+specified for the device it is disabled, preventing the VM from notifying or
+being notified by other VMs (a warning will be displayed to the user to inform
+the IRQ mechanism is disabled). The shared memory region is always present.
+
+The MMRs (INTRMASK, INTRSTATUS, IVPOSITION, and DOORBELL registers) offsets at
+the MMR region, and their functions, follow the ivshmem spec, so they work
+exactly as in the ivshmem PCI device (see ./specs/ivshmem-spec.txt).
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 4fc6b29b43..a643cfac3a 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -68,6 +68,11 @@ config IVSHMEM_DEVICE
default y if PCI_DEVICES
depends on PCI && LINUX && IVSHMEM && MSI_NONBROKEN
+config IVSHMEM_FLAT_DEVICE
+ bool
+ default y
+ depends on LINUX && IVSHMEM
+
config ECCMEMCTL
bool
select ECC
diff --git a/hw/misc/ivshmem-flat.c b/hw/misc/ivshmem-flat.c
new file mode 100644
index 0000000000..833ee2fefb
--- /dev/null
+++ b/hw/misc/ivshmem-flat.c
@@ -0,0 +1,463 @@
+/*
+ * Inter-VM Shared Memory Flat Device
+ *
+ * SPDX-FileCopyrightText: 2023 Linaro Ltd.
+ * SPDX-FileContributor: Gustavo Romero <gustavo.romero@linaro.org>
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qemu/error-report.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties-system.h"
+#include "hw/sysbus.h"
+#include "chardev/char-fe.h"
+#include "exec/address-spaces.h"
+#include "trace.h"
+
+#include "hw/misc/ivshmem-flat.h"
+
+static int64_t ivshmem_flat_recv_msg(IvshmemFTState *s, int *pfd)
+{
+ int64_t msg;
+ int n, ret;
+
+ n = 0;
+ do {
+ ret = qemu_chr_fe_read_all(&s->server_chr, (uint8_t *)&msg + n,
+ sizeof(msg) - n);
+ if (ret < 0) {
+ if (ret == -EINTR) {
+ continue;
+ }
+ exit(1);
+ }
+ n += ret;
+ } while (n < sizeof(msg));
+
+ if (pfd) {
+ *pfd = qemu_chr_fe_get_msgfd(&s->server_chr);
+ }
+ return le64_to_cpu(msg);
+}
+
+static void ivshmem_flat_irq_handler(void *opaque)
+{
+ VectorInfo *vi = opaque;
+ EventNotifier *e = &vi->event_notifier;
+ uint16_t vector_id;
+ const VectorInfo (*v)[64];
+
+ assert(e->initialized);
+
+ vector_id = vi->id;
+
+ /*
+ * The vector info struct is passed to the handler via the 'opaque' pointer.
+ * This struct pointer allows the retrieval of the vector ID and its
+ * associated event notifier. However, for triggering an interrupt using
+ * qemu_set_irq, it's necessary to also have a pointer to the device state,
+ * i.e., a pointer to the IvshmemFTState struct. Since the vector info
+ * struct is contained within the IvshmemFTState struct, its pointer can be
+ * used to obtain the pointer to IvshmemFTState through simple pointer math.
+ */
+ v = (void *)(vi - vector_id); /* v = &IvshmemPeer->vector[0] */
+ IvshmemPeer *own_peer = container_of(v, IvshmemPeer, vector);
+ IvshmemFTState *s = container_of(own_peer, IvshmemFTState, own);
+
+ /* Clear event */
+ if (!event_notifier_test_and_clear(e)) {
+ return;
+ }
+
+ trace_ivshmem_flat_irq_handler(vector_id);
+
+ /*
+ * Toggle device's output line, which is connected to interrupt controller,
+ * generating an interrupt request to the CPU.
+ */
+ qemu_irq_pulse(s->irq);
+}
+
+static IvshmemPeer *ivshmem_flat_find_peer(IvshmemFTState *s, uint16_t peer_id)
+{
+ IvshmemPeer *peer;
+
+ /* Own ID */
+ if (s->own.id == peer_id) {
+ return &s->own;
+ }
+
+ /* Peer ID */
+ QTAILQ_FOREACH(peer, &s->peer, next) {
+ if (peer->id == peer_id) {
+ return peer;
+ }
+ }
+
+ return NULL;
+}
+
+static IvshmemPeer *ivshmem_flat_add_peer(IvshmemFTState *s, uint16_t peer_id)
+{
+ IvshmemPeer *new_peer;
+
+ new_peer = g_malloc0(sizeof(*new_peer));
+ new_peer->id = peer_id;
+ new_peer->vector_counter = 0;
+
+ QTAILQ_INSERT_TAIL(&s->peer, new_peer, next);
+
+ trace_ivshmem_flat_new_peer(peer_id);
+
+ return new_peer;
+}
+
+static void ivshmem_flat_remove_peer(IvshmemFTState *s, uint16_t peer_id)
+{
+ IvshmemPeer *peer;
+
+ peer = ivshmem_flat_find_peer(s, peer_id);
+ assert(peer);
+
+ QTAILQ_REMOVE(&s->peer, peer, next);
+ for (int n = 0; n < peer->vector_counter; n++) {
+ int efd;
+ efd = event_notifier_get_fd(&(peer->vector[n].event_notifier));
+ close(efd);
+ }
+
+ g_free(peer);
+}
+
+static void ivshmem_flat_add_vector(IvshmemFTState *s, IvshmemPeer *peer,
+ int vector_fd)
+{
+ if (peer->vector_counter >= IVSHMEM_MAX_VECTOR_NUM) {
+ trace_ivshmem_flat_add_vector_failure(peer->vector_counter,
+ vector_fd, peer->id);
+ close(vector_fd);
+
+ return;
+ }
+
+ trace_ivshmem_flat_add_vector_success(peer->vector_counter,
+ vector_fd, peer->id);
+
+ /*
+ * Set vector ID and its associated eventfd notifier and add them to the
+ * peer.
+ */
+ peer->vector[peer->vector_counter].id = peer->vector_counter;
+ g_unix_set_fd_nonblocking(vector_fd, true, NULL);
+ event_notifier_init_fd(&peer->vector[peer->vector_counter].event_notifier,
+ vector_fd);
+
+ /*
+ * If it's the device's own ID, register also the handler for the eventfd
+ * so the device can be notified by the other peers.
+ */
+ if (peer == &s->own) {
+ qemu_set_fd_handler(vector_fd, ivshmem_flat_irq_handler, NULL,
+ &peer->vector);
+ }
+
+ peer->vector_counter++;
+}
+
+static void ivshmem_flat_process_msg(IvshmemFTState *s, uint64_t msg, int fd)
+{
+ uint16_t peer_id;
+ IvshmemPeer *peer;
+
+ peer_id = msg & 0xFFFF;
+ peer = ivshmem_flat_find_peer(s, peer_id);
+
+ if (!peer) {
+ peer = ivshmem_flat_add_peer(s, peer_id);
+ }
+
+ if (fd >= 0) {
+ ivshmem_flat_add_vector(s, peer, fd);
+ } else { /* fd == -1, which is received when peers disconnect. */
+ ivshmem_flat_remove_peer(s, peer_id);
+ }
+}
+
+static int ivshmem_flat_can_receive_data(void *opaque)
+{
+ IvshmemFTState *s = opaque;
+
+ assert(s->msg_buffered_bytes < sizeof(s->msg_buf));
+ return sizeof(s->msg_buf) - s->msg_buffered_bytes;
+}
+
+static void ivshmem_flat_read_msg(void *opaque, const uint8_t *buf, int size)
+{
+ IvshmemFTState *s = opaque;
+ int fd;
+ int64_t msg;
+
+ assert(size >= 0 && s->msg_buffered_bytes + size <= sizeof(s->msg_buf));
+ memcpy((unsigned char *)&s->msg_buf + s->msg_buffered_bytes, buf, size);
+ s->msg_buffered_bytes += size;
+ if (s->msg_buffered_bytes < sizeof(s->msg_buf)) {
+ return;
+ }
+ msg = le64_to_cpu(s->msg_buf);
+ s->msg_buffered_bytes = 0;
+
+ fd = qemu_chr_fe_get_msgfd(&s->server_chr);
+
+ ivshmem_flat_process_msg(s, msg, fd);
+}
+
+static uint64_t ivshmem_flat_iomem_read(void *opaque,
+ hwaddr offset, unsigned size)
+{
+ IvshmemFTState *s = opaque;
+ uint32_t ret;
+
+ trace_ivshmem_flat_read_mmr(offset);
+
+ switch (offset) {
+ case INTMASK:
+ ret = 0; /* Ignore read since all bits are reserved in rev 1. */
+ break;
+ case INTSTATUS:
+ ret = 0; /* Ignore read since all bits are reserved in rev 1. */
+ break;
+ case IVPOSITION:
+ ret = s->own.id;
+ break;
+ case DOORBELL:
+ trace_ivshmem_flat_read_mmr_doorbell(); /* DOORBELL is write-only */
+ ret = 0;
+ break;
+ default:
+ /* Should never reach out here due to iomem map range being exact */
+ trace_ivshmem_flat_read_write_mmr_invalid(offset);
+ ret = 0;
+ }
+
+ return ret;
+}
+
+static int ivshmem_flat_interrupt_peer(IvshmemFTState *s,
+ uint16_t peer_id, uint16_t vector_id)
+{
+ IvshmemPeer *peer;
+
+ peer = ivshmem_flat_find_peer(s, peer_id);
+ if (!peer) {
+ trace_ivshmem_flat_interrupt_invalid_peer(peer_id);
+ return 1;
+ }
+
+ event_notifier_set(&(peer->vector[vector_id].event_notifier));
+
+ return 0;
+}
+
+static void ivshmem_flat_iomem_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+ IvshmemFTState *s = opaque;
+ uint16_t peer_id = (value >> 16) & 0xFFFF;
+ uint16_t vector_id = value & 0xFFFF;
+
+ trace_ivshmem_flat_write_mmr(offset);
+
+ switch (offset) {
+ case INTMASK:
+ break;
+ case INTSTATUS:
+ break;
+ case IVPOSITION:
+ break;
+ case DOORBELL:
+ trace_ivshmem_flat_interrupt_peer(peer_id, vector_id);
+ ivshmem_flat_interrupt_peer(s, peer_id, vector_id);
+ break;
+ default:
+ /* Should never reach out here due to iomem map range being exact. */
+ trace_ivshmem_flat_read_write_mmr_invalid(offset);
+ break;
+ }
+
+ return;
+}
+
+static const MemoryRegionOps ivshmem_flat_ops = {
+ .read = ivshmem_flat_iomem_read,
+ .write = ivshmem_flat_iomem_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ .impl = { /* Read/write aligned at 32 bits. */
+ .min_access_size = 4,
+ .max_access_size = 4,
+ },
+};
+
+static void ivshmem_flat_instance_init(Object *obj)
+{
+ SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+ IvshmemFTState *s = IVSHMEM_FLAT(obj);
+
+ /*
+ * Init mem region for 4 MMRs (ivshmem_registers),
+ * 32 bits each => 16 bytes (0x10).
+ */
+ memory_region_init_io(&s->iomem, obj, &ivshmem_flat_ops, s,
+ "ivshmem-mmio", 0x10);
+ sysbus_init_mmio(sbd, &s->iomem);
+
+ /*
+ * Create one output IRQ that will be connect to the
+ * machine's interrupt controller.
+ */
+ sysbus_init_irq(sbd, &s->irq);
+
+ QTAILQ_INIT(&s->peer);
+}
+
+static bool ivshmem_flat_connect_server(DeviceState *dev, Error **errp)
+{
+ IvshmemFTState *s = IVSHMEM_FLAT(dev);
+ SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+ int64_t protocol_version, msg;
+ int shmem_fd;
+ uint16_t peer_id;
+ struct stat fdstat;
+
+ /* Check ivshmem server connection. */
+ if (!qemu_chr_fe_backend_connected(&s->server_chr)) {
+ error_setg(errp, "ivshmem server socket not specified or incorret."
+ " Can't create device.");
+ return false;
+ }
+
+ /*
+ * Message sequence from server on new connection:
+ * _____________________________________
+ * |STEP| uint64_t msg | int fd |
+ * -------------------------------------
+ *
+ * 0 PROTOCOL -1 \
+ * 1 OWN PEER ID -1 |-- Header/Greeting
+ * 2 -1 shmem fd /
+ *
+ * 3 PEER IDx Other peer's Vector 0 eventfd
+ * 4 PEER IDx Other peer's Vector 1 eventfd
+ * . .
+ * . .
+ * . .
+ * N PEER IDy Other peer's Vector 0 eventfd
+ * N+1 PEER IDy Other peer's Vector 1 eventfd
+ * . .
+ * . .
+ * . .
+ *
+ * ivshmem_flat_recv_msg() calls return 'msg' and 'fd'.
+ *
+ * See ./docs/specs/ivshmem-spec.txt for details on the protocol.
+ */
+
+ /* Step 0 */
+ protocol_version = ivshmem_flat_recv_msg(s, NULL);
+
+ /* Step 1 */
+ msg = ivshmem_flat_recv_msg(s, NULL);
+ peer_id = 0xFFFF & msg;
+ s->own.id = peer_id;
+ s->own.vector_counter = 0;
+
+ trace_ivshmem_flat_proto_ver_own_id(protocol_version, s->own.id);
+
+ /* Step 2 */
+ msg = ivshmem_flat_recv_msg(s, &shmem_fd);
+ /* Map shmem fd and MMRs into memory regions. */
+ if (msg != -1 || shmem_fd < 0) {
+ error_setg(errp, "Could not receive valid shmem fd."
+ " Can't create device!");
+ return false;
+ }
+
+ if (fstat(shmem_fd, &fdstat) != 0) {
+ error_setg(errp, "Could not determine shmem fd size."
+ " Can't create device!");
+ return false;
+ }
+ trace_ivshmem_flat_shmem_size(shmem_fd, fdstat.st_size);
+
+ /*
+ * Shmem size provided by the ivshmem server must be equal to
+ * device's shmem size.
+ */
+ if (fdstat.st_size != s->shmem_size) {
+ error_setg(errp, "Can't map shmem fd: shmem size different"
+ " from device size!");
+ return false;
+ }
+
+ /*
+ * Beyond step 2 ivshmem_process_msg, called by ivshmem_flat_read_msg
+ * handler -- when data is available on the server socket -- will handle
+ * the additional messages that will be generated by the server as peers
+ * connect or disconnect.
+ */
+ qemu_chr_fe_set_handlers(&s->server_chr, ivshmem_flat_can_receive_data,
+ ivshmem_flat_read_msg, NULL, NULL, s, NULL, true);
+
+ memory_region_init_ram_from_fd(&s->shmem, OBJECT(s),
+ "ivshmem-shmem", s->shmem_size,
+ RAM_SHARED, shmem_fd, 0, NULL);
+ sysbus_init_mmio(sbd, &s->shmem);
+
+ return true;
+}
+
+static void ivshmem_flat_realize(DeviceState *dev, Error **errp)
+{
+ if (!ivshmem_flat_connect_server(dev, errp)) {
+ return;
+ }
+}
+
+static Property ivshmem_flat_props[] = {
+ DEFINE_PROP_CHR("chardev", IvshmemFTState, server_chr),
+ DEFINE_PROP_UINT32("shmem-size", IvshmemFTState, shmem_size, 4 * MiB),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ivshmem_flat_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+
+ dc->hotpluggable = true;
+ dc->realize = ivshmem_flat_realize;
+
+ set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+ device_class_set_props(dc, ivshmem_flat_props);
+
+ /* Reason: Must be wired up in code (sysbus MRs and IRQ) */
+ dc->user_creatable = false;
+}
+
+static const TypeInfo ivshmem_flat_info = {
+ .name = TYPE_IVSHMEM_FLAT,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(IvshmemFTState),
+ .instance_init = ivshmem_flat_instance_init,
+ .class_init = ivshmem_flat_class_init,
+};
+
+static void ivshmem_flat_register_types(void)
+{
+ type_register_static(&ivshmem_flat_info);
+}
+
+type_init(ivshmem_flat_register_types);
diff --git a/hw/misc/meson.build b/hw/misc/meson.build
index e4ef1da5a5..84dff09f5d 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -38,7 +38,9 @@ system_ss.add(when: 'CONFIG_SIFIVE_U_PRCI', if_true: files('sifive_u_prci.c'))
subdir('macio')
+# ivshmem devices
system_ss.add(when: 'CONFIG_IVSHMEM_DEVICE', if_true: files('ivshmem.c'))
+system_ss.add(when: 'CONFIG_IVSHMEM_FLAT_DEVICE', if_true: files('ivshmem-flat.c'))
system_ss.add(when: 'CONFIG_ALLWINNER_SRAMC', if_true: files('allwinner-sramc.c'))
system_ss.add(when: 'CONFIG_ALLWINNER_A10_CCM', if_true: files('allwinner-a10-ccm.c'))
diff --git a/hw/misc/trace-events b/hw/misc/trace-events
index 5f5bc92222..cba03743dd 100644
--- a/hw/misc/trace-events
+++ b/hw/misc/trace-events
@@ -341,3 +341,20 @@ djmemc_write(int reg, uint64_t value, unsigned int size) "reg=0x%x value=0x%"PRI
# iosb.c
iosb_read(int reg, uint64_t value, unsigned int size) "reg=0x%x value=0x%"PRIx64" size=%u"
iosb_write(int reg, uint64_t value, unsigned int size) "reg=0x%x value=0x%"PRIx64" size=%u"
+
+# ivshmem-flat.c
+ivshmem_flat_irq_handler(uint16_t vector_id) "Caught interrupt request: vector %d"
+ivshmem_flat_new_peer(uint16_t peer_id) "New peer ID: %d"
+ivshmem_flat_add_vector_failure(uint16_t vector_id, uint32_t vector_fd, uint16_t peer_id) "Failed to add vector %u (fd = %u) to peer ID %u, maximum number of vectors reached"
+ivshmem_flat_add_vector_success(uint16_t vector_id, uint32_t vector_fd, uint16_t peer_id) "Successful addition of vector %u (fd = %u) to peer ID %u"
+ivshmem_flat_irq_resolved(const char *irq_qompath) "IRQ QOM path '%s' correctly resolved"
+ivshmem_flat_proto_ver_own_id(uint64_t proto_ver, uint16_t peer_id) "Protocol Version = 0x%"PRIx64", Own Peer ID = %u"
+ivshmem_flat_shmem_size(int fd, uint64_t size) "Shmem fd (%d) total size is %"PRIu64" byte(s)"
+ivshmem_flat_shmem_map(uint64_t addr) "Mapping shmem @ 0x%"PRIx64
+ivshmem_flat_mmio_map(uint64_t addr) "Mapping MMRs @ 0x%"PRIx64
+ivshmem_flat_read_mmr(uint64_t addr_offset) "Read access at offset %"PRIu64
+ivshmem_flat_read_mmr_doorbell(void) "DOORBELL register is write-only!"
+ivshmem_flat_read_write_mmr_invalid(uint64_t addr_offset) "No ivshmem register mapped at offset %"PRIu64
+ivshmem_flat_interrupt_invalid_peer(uint16_t peer_id) "Can't interrupt non-existing peer %u"
+ivshmem_flat_write_mmr(uint64_t addr_offset) "Write access at offset %"PRIu64
+ivshmem_flat_interrupt_peer(uint16_t peer_id, uint16_t vector_id) "Interrupting peer ID %u, vector %u..."
diff --git a/include/hw/misc/ivshmem-flat.h b/include/hw/misc/ivshmem-flat.h
new file mode 100644
index 0000000000..97ca0ddce6
--- /dev/null
+++ b/include/hw/misc/ivshmem-flat.h
@@ -0,0 +1,85 @@
+/*
+ * Inter-VM Shared Memory Flat Device
+ *
+ * SPDX-FileCopyrightText: 2023 Linaro Ltd.
+ * SPDX-FileContributor: Gustavo Romero <gustavo.romero@linaro.org>
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ */
+
+#ifndef IVSHMEM_FLAT_H
+#define IVSHMEM_FLAT_H
+
+#include "qemu/queue.h"
+#include "qemu/event_notifier.h"
+#include "chardev/char-fe.h"
+#include "exec/memory.h"
+#include "qom/object.h"
+#include "hw/sysbus.h"
+
+#define IVSHMEM_MAX_VECTOR_NUM 64
+
+/*
+ * QEMU interface:
+ * + QOM property "chardev" is the character device id of the ivshmem server
+ * socket
+ * + QOM property "shmem-size" sets the size of the RAM region shared between
+ * the device and the ivshmem server
+ * + sysbus MMIO region 0: device I/O mapped registers
+ * + sysbus MMIO region 1: shared memory with ivshmem server
+ * + sysbus IRQ 0: single output interrupt
+ */
+
+#define TYPE_IVSHMEM_FLAT "ivshmem-flat"
+typedef struct IvshmemFTState IvshmemFTState;
+
+DECLARE_INSTANCE_CHECKER(IvshmemFTState, IVSHMEM_FLAT, TYPE_IVSHMEM_FLAT)
+
+/* Ivshmem registers. See ./docs/specs/ivshmem-spec.txt for details. */
+enum ivshmem_registers {
+ INTMASK = 0,
+ INTSTATUS = 4,
+ IVPOSITION = 8,
+ DOORBELL = 12,
+};
+
+typedef struct VectorInfo {
+ EventNotifier event_notifier;
+ uint16_t id;
+} VectorInfo;
+
+typedef struct IvshmemPeer {
+ QTAILQ_ENTRY(IvshmemPeer) next;
+ VectorInfo vector[IVSHMEM_MAX_VECTOR_NUM];
+ int vector_counter;
+ uint16_t id;
+} IvshmemPeer;
+
+struct IvshmemFTState {
+ SysBusDevice parent_obj;
+
+ uint64_t msg_buf;
+ int msg_buffered_bytes;
+
+ QTAILQ_HEAD(, IvshmemPeer) peer;
+ IvshmemPeer own;
+
+ CharBackend server_chr;
+
+ /* IRQ */
+ qemu_irq irq;
+
+ /* I/O registers */
+ MemoryRegion iomem;
+ uint32_t intmask;
+ uint32_t intstatus;
+ uint32_t ivposition;
+ uint32_t doorbell;
+
+ /* Shared memory */
+ MemoryRegion shmem;
+ int shmem_fd;
+ uint32_t shmem_size;
+};
+
+#endif /* IVSHMEM_FLAT_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 2/6] hw/misc/ivshmem-flat: Allow device to wire itself on sysbus
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
2024-02-22 22:22 ` [PATCH 1/6] hw/misc/ivshmem: " Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-22 22:22 ` [PATCH 3/6] hw/arm: Allow some machines to use the ivshmem-flat device Gustavo Romero
` (4 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
This commit enables the ivshmem-flat device to wire itself on sysbus. It
maps the device's Memory-Mapped Registers (MMRs) and shared memory
(shmem) into the VM's memory layout and also allows connection to an
input IRQ so that the device can trigger an interrupt for notification.
Three device options are introduced to control how this is done:
x-bus-address-iomem, x-bus-address-shmem, and x-irq-qompath.
The following is an example on how to create the ivshmem-flat device on
a Stellaris machine:
$ qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic
-net none -chardev stdio,id=con,mux=on
-serial chardev:con -mon chardev=con,mode=readline
-chardev socket,path=/tmp/ivshmem_socket,id=ivshmem_flat
-device ivshmem-flat,chardev=ivshmem_flat,x-irq-qompath='/machine/soc/v7m/nvic/unnamed-gpio-in[0]',x-bus-address-iomem=0x400FF000,x-bus-address-shmem=0x40100000
-kernel zephyr_kernel.elf
The IRQ QOM path option for the target machine can be determined by
creating the VM without the ivshmem-flat device, going to the QEMU
console and listing the QOM nodes with 'info qom-tree'. In the Stellaris
example above the input IRQ is in the machine's NVIC Interrupt
Controller.
If 'x-irq-qompath' is not provided the device won't be able to be
interrupted by other VMs (peers) and only the shared memory (shmem)
feature will be supported.
The MMRs for status and control (notification) are mapped to the MMIO
region at 'x-bus-address-iomem', whilst the shared memory region start
is mapped at address specified by 'x-bus-address-shmem'.
Message-ID: <20231127052024.435743-2-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
docs/system/devices/ivshmem-flat.rst | 57 +++++++++++++++++++++
hw/core/sysbus-fdt.c | 2 +
hw/misc/ivshmem-flat.c | 74 ++++++++++++++++++++++++++--
include/hw/misc/ivshmem-flat.h | 9 ++++
4 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/docs/system/devices/ivshmem-flat.rst b/docs/system/devices/ivshmem-flat.rst
index 1f97052804..ddc3477f52 100644
--- a/docs/system/devices/ivshmem-flat.rst
+++ b/docs/system/devices/ivshmem-flat.rst
@@ -31,3 +31,60 @@ the IRQ mechanism is disabled). The shared memory region is always present.
The MMRs (INTRMASK, INTRSTATUS, IVPOSITION, and DOORBELL registers) offsets at
the MMR region, and their functions, follow the ivshmem spec, so they work
exactly as in the ivshmem PCI device (see ./specs/ivshmem-spec.txt).
+
+
+Device Options
+--------------
+
+The required options to create an ivshmem-flat device are: (a) the UNIX
+socket where the ivshmem server is listening, usually ``/tmp/ivshmem_socket``;
+(b) the address where to map the MMRs (``x-bus-address-iomem=``) in the VM
+memory layout; and (c) the address where to map the shared memory in the VM
+memory layout (``x-bus-address-shmem=``). Both (a) and (b) depend on the VM
+being used, as the MMRs and shmem must be mapped to a region not previously
+occupied in the VM.
+
+Example:
+
+.. parsed-literal::
+
+ |qemu-system-arm| -chardev socket,path=/tmp/ivshmem_socket,id=ivshmem_flat -device ivshmem-flat,chardev=ivshmem_flat,x-irq-qompath='/machine/soc/v7m/nvic/unnamed-gpio-in[0]',x-bus-address-iomem=0x400FF000,x-bus-address-shmem=0x40100000
+
+The other option, ``x-irq-qompath=``, is not required if the user doesn't want
+the device supporting notifications.
+
+``x-irq-qompath``. Used to inform the device which IRQ input line it can attach
+to enable the notification mechanism (IRQ). The ivshmem-flat device currently
+only supports notification via vector 0. Notifications via other vectors are
+ignored. (optional)
+
+Two examples for different machines follow.
+
+Stellaris machine (``- machine lm3s6965evb``):
+
+::
+
+ x-irq-qompath=/machine/soc/v7m/nvic/unnamed-gpio-in[0]
+
+Arm mps2-an385 machine (``-machine mps2-an385``):
+
+::
+
+ x-irq-qompath=/machine/armv7m/nvic/unnamed-gpio-in[0]
+
+The available IRQ input lines on a given VM that the ivshmem-flat device can be
+attached to can be found from the QEMU monitor (Ctrl-a + c) with:
+
+(qemu) info qom-tree
+
+``x-bus-address-iomem``. Allows changing the address where the MMRs are mapped
+into the VM memory layout. (required)
+
+ ``x-bus-address-shmem``. Allows changing the address where the shared memory
+region is mapped into the VM memory layout. (required)
+
+``shmem-size``. Allows changing the size (in bytes) of shared memory region.
+Default is 4 MiB, which is the same default used by the ivshmem server, so
+usually it's not necessary to change it. The size must match the size of the
+shared memory reserverd and informed by the ivshmem server, otherwise device
+creation fails. (optional)
diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
index eebcd28f9a..40d7356cae 100644
--- a/hw/core/sysbus-fdt.c
+++ b/hw/core/sysbus-fdt.c
@@ -31,6 +31,7 @@
#include "qemu/error-report.h"
#include "sysemu/device_tree.h"
#include "sysemu/tpm.h"
+#include "hw/misc/ivshmem-flat.h"
#include "hw/platform-bus.h"
#include "hw/vfio/vfio-platform.h"
#include "hw/vfio/vfio-calxeda-xgmac.h"
@@ -495,6 +496,7 @@ static const BindingEntry bindings[] = {
TYPE_BINDING(TYPE_TPM_TIS_SYSBUS, add_tpm_tis_fdt_node),
#endif
TYPE_BINDING(TYPE_RAMFB_DEVICE, no_fdt_node),
+ TYPE_BINDING(TYPE_IVSHMEM_FLAT, no_fdt_node),
TYPE_BINDING("", NULL), /* last element */
};
diff --git a/hw/misc/ivshmem-flat.c b/hw/misc/ivshmem-flat.c
index 833ee2fefb..972281ca57 100644
--- a/hw/misc/ivshmem-flat.c
+++ b/hw/misc/ivshmem-flat.c
@@ -420,16 +420,86 @@ static bool ivshmem_flat_connect_server(DeviceState *dev, Error **errp)
return true;
}
+static bool ivshmem_flat_sysbus_wire(DeviceState *dev, Error **errp)
+{
+ IvshmemFTState *s = IVSHMEM_FLAT(dev);
+ SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+ if (s->x_sysbus_mmio_addr != UINT64_MAX) {
+ trace_ivshmem_flat_mmio_map(s->x_sysbus_mmio_addr);
+ sysbus_mmio_map(sbd, 0, s->x_sysbus_mmio_addr);
+ } else {
+ error_setg(errp, "No address for iomem (MMRs) specified. Can't create"
+ " ivshmem-flat device. Use 'x-bus-address-iomem'"
+ " option.");
+ return false;
+ }
+
+ if (s->x_sysbus_shmem_addr != UINT64_MAX) {
+ trace_ivshmem_flat_shmem_map(s->x_sysbus_shmem_addr);
+ sysbus_mmio_map(sbd, 1, s->x_sysbus_shmem_addr);
+ } else {
+ error_setg(errp, "No address for shmem specified. Can't create"
+ " ivshmem-flat device. Use 'x-bus-address-shmem'"
+ " option.");
+ return false;
+ }
+
+ /* Check for input IRQ line, if it's provided, connect it. */
+ if (s->x_sysbus_irq_qompath) {
+ Object *oirq;
+ bool ambiguous = false;
+ qemu_irq irq;
+
+ oirq = object_resolve_path_type(s->x_sysbus_irq_qompath, TYPE_IRQ,
+ &ambiguous);
+ if (ambiguous) {
+ error_setg(errp, "Specified IRQ is ambiguous. Can't create"
+ " ivshmem-flat device.");
+ return false;
+ }
+
+ if (!oirq) {
+ error_setg(errp, "Can't resolve IRQ QOM path.");
+ return false;
+ }
+ irq = (qemu_irq)oirq;
+ trace_ivshmem_flat_irq_resolved(s->x_sysbus_irq_qompath);
+
+ /*
+ * Connect device out irq line to interrupt controller input irq line.
+ */
+ sysbus_connect_irq(sbd, 0, irq);
+ } else {
+ /*
+ * If input IRQ is not provided, warn user the device won't be able
+ * to trigger any interrupts.
+ */
+ warn_report("Input IRQ not specified, device won't be able"
+ " to handle IRQs!");
+ }
+
+ return true;
+}
+
static void ivshmem_flat_realize(DeviceState *dev, Error **errp)
{
if (!ivshmem_flat_connect_server(dev, errp)) {
return;
}
+ if (!ivshmem_flat_sysbus_wire(dev, errp)) {
+ return;
+ }
}
static Property ivshmem_flat_props[] = {
DEFINE_PROP_CHR("chardev", IvshmemFTState, server_chr),
DEFINE_PROP_UINT32("shmem-size", IvshmemFTState, shmem_size, 4 * MiB),
+ DEFINE_PROP_STRING("x-irq-qompath", IvshmemFTState, x_sysbus_irq_qompath),
+ DEFINE_PROP_UINT64("x-bus-address-iomem", IvshmemFTState,
+ x_sysbus_mmio_addr, UINT64_MAX),
+ DEFINE_PROP_UINT64("x-bus-address-shmem", IvshmemFTState,
+ x_sysbus_shmem_addr, UINT64_MAX),
DEFINE_PROP_END_OF_LIST(),
};
@@ -438,13 +508,11 @@ static void ivshmem_flat_class_init(ObjectClass *klass, void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
dc->hotpluggable = true;
+ dc->user_creatable = true;
dc->realize = ivshmem_flat_realize;
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
device_class_set_props(dc, ivshmem_flat_props);
-
- /* Reason: Must be wired up in code (sysbus MRs and IRQ) */
- dc->user_creatable = false;
}
static const TypeInfo ivshmem_flat_info = {
diff --git a/include/hw/misc/ivshmem-flat.h b/include/hw/misc/ivshmem-flat.h
index 97ca0ddce6..d5b6d99ae4 100644
--- a/include/hw/misc/ivshmem-flat.h
+++ b/include/hw/misc/ivshmem-flat.h
@@ -25,6 +25,12 @@
* socket
* + QOM property "shmem-size" sets the size of the RAM region shared between
* the device and the ivshmem server
+ * + QOM property "x-bus-address-iomem" is the base address of the I/O region
+ * on the main system bus
+ * + QOM property "x-bus-address-shmem" is the base address of the shared RAM
+ * region on the main system bus
+ * + QOM property "x-irq-qompath" is the QOM path of the interrupt being
+ * notified
* + sysbus MMIO region 0: device I/O mapped registers
* + sysbus MMIO region 1: shared memory with ivshmem server
* + sysbus IRQ 0: single output interrupt
@@ -68,9 +74,11 @@ struct IvshmemFTState {
/* IRQ */
qemu_irq irq;
+ char *x_sysbus_irq_qompath;
/* I/O registers */
MemoryRegion iomem;
+ uint64_t x_sysbus_mmio_addr;
uint32_t intmask;
uint32_t intstatus;
uint32_t ivposition;
@@ -80,6 +88,7 @@ struct IvshmemFTState {
MemoryRegion shmem;
int shmem_fd;
uint32_t shmem_size;
+ uint64_t x_sysbus_shmem_addr;
};
#endif /* IVSHMEM_FLAT_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 3/6] hw/arm: Allow some machines to use the ivshmem-flat device
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
2024-02-22 22:22 ` [PATCH 1/6] hw/misc/ivshmem: " Gustavo Romero
2024-02-22 22:22 ` [PATCH 2/6] hw/misc/ivshmem-flat: Allow device to wire itself on sysbus Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-22 22:22 ` [PATCH 4/6] hw/misc/ivshmem: Rename ivshmem to ivshmem-pci Gustavo Romero
` (3 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
Allow Arm machine lm3s6965evb and the mps2 ones, like the mps2-an385, to
use the ivshmem-flat device.
Message-ID: <20231127052024.435743-2-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
hw/arm/mps2.c | 3 +++
hw/arm/stellaris.c | 3 +++
hw/arm/virt.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/hw/arm/mps2.c b/hw/arm/mps2.c
index 50919ee46d..fe158dfbc0 100644
--- a/hw/arm/mps2.c
+++ b/hw/arm/mps2.c
@@ -42,6 +42,7 @@
#include "hw/timer/cmsdk-apb-dualtimer.h"
#include "hw/misc/mps2-scc.h"
#include "hw/misc/mps2-fpgaio.h"
+#include "hw/misc/ivshmem-flat.h"
#include "hw/ssi/pl022.h"
#include "hw/i2c/arm_sbcon_i2c.h"
#include "hw/net/lan9118.h"
@@ -472,6 +473,8 @@ static void mps2_class_init(ObjectClass *oc, void *data)
mc->max_cpus = 1;
mc->default_ram_size = 16 * MiB;
mc->default_ram_id = "mps.ram";
+
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_IVSHMEM_FLAT);
}
static void mps2_an385_class_init(ObjectClass *oc, void *data)
diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
index a2f998bf9e..e25858f232 100644
--- a/hw/arm/stellaris.c
+++ b/hw/arm/stellaris.c
@@ -28,6 +28,7 @@
#include "hw/watchdog/cmsdk-apb-watchdog.h"
#include "migration/vmstate.h"
#include "hw/misc/unimp.h"
+#include "hw/misc/ivshmem-flat.h"
#include "hw/timer/stellaris-gptm.h"
#include "hw/qdev-clock.h"
#include "qom/object.h"
@@ -1404,6 +1405,8 @@ static void lm3s6965evb_class_init(ObjectClass *oc, void *data)
mc->init = lm3s6965evb_init;
mc->ignore_memory_transaction_failures = true;
mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
+
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_IVSHMEM_FLAT);
}
static const TypeInfo lm3s6965evb_type = {
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 0af1943697..6c0917f3b2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -84,6 +84,7 @@
#include "hw/virtio/virtio-iommu.h"
#include "hw/char/pl011.h"
#include "qemu/guest-random.h"
+#include "hw/misc/ivshmem-flat.h"
#define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -2973,6 +2974,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_IVSHMEM_FLAT);
#ifdef CONFIG_TPM
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
#endif
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 4/6] hw/misc/ivshmem: Rename ivshmem to ivshmem-pci
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
` (2 preceding siblings ...)
2024-02-22 22:22 ` [PATCH 3/6] hw/arm: Allow some machines to use the ivshmem-flat device Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-22 22:22 ` [PATCH 5/6] tests/qtest: Reorganize common code in ivshmem-test Gustavo Romero
` (2 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
Because now there is also an MMIO ivshmem device (ivshmem-flat.c), and
ivshmem.c is a PCI specific implementation, rename it to ivshmem-pci.c.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231127052024.435743-5-gustavo.romero@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
hw/misc/{ivshmem.c => ivshmem-pci.c} | 0
hw/misc/meson.build | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename hw/misc/{ivshmem.c => ivshmem-pci.c} (100%)
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem-pci.c
similarity index 100%
rename from hw/misc/ivshmem.c
rename to hw/misc/ivshmem-pci.c
diff --git a/hw/misc/meson.build b/hw/misc/meson.build
index 84dff09f5d..4a9369082b 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -39,7 +39,7 @@ system_ss.add(when: 'CONFIG_SIFIVE_U_PRCI', if_true: files('sifive_u_prci.c'))
subdir('macio')
# ivshmem devices
-system_ss.add(when: 'CONFIG_IVSHMEM_DEVICE', if_true: files('ivshmem.c'))
+system_ss.add(when: 'CONFIG_IVSHMEM_DEVICE', if_true: files('ivshmem-pci.c'))
system_ss.add(when: 'CONFIG_IVSHMEM_FLAT_DEVICE', if_true: files('ivshmem-flat.c'))
system_ss.add(when: 'CONFIG_ALLWINNER_SRAMC', if_true: files('allwinner-sramc.c'))
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 5/6] tests/qtest: Reorganize common code in ivshmem-test
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
` (3 preceding siblings ...)
2024-02-22 22:22 ` [PATCH 4/6] hw/misc/ivshmem: Rename ivshmem to ivshmem-pci Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-26 7:56 ` Thomas Huth
2024-02-22 22:22 ` [PATCH 6/6] tests/qtest: Add ivshmem-flat test Gustavo Romero
2024-02-28 6:29 ` [PATCH 0/6] Add ivshmem-flat device Markus Armbruster
6 siblings, 1 reply; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
This commit reorganizes the ivshmem-test qtest by moving common structs,
functions, and code that can be utilized by other ivshmem qtests into
two new files: ivshmem-utils.h and ivshmem-utils.c.
Enum Reg, struct ServerThread, and mktempshm() have been relocated to
these new files. Two new functions have been introduced to handle the
ivshmem server start/stop: test_ivshmem_server_{start,stop}.
To accommodate the new way for starting/stopping the ivshmem server,
struct ServerThread now includes two new members: 'server', previously
present but not a member of any struct; and 'status', a new member of a
new type, ServerStartStatus, used to track and handle service
termination properly.
Additionally, a new function, mktempsocket(), has been added to help
create a unix socket filename, similar to what mktempshm() does for the
creation of a shm file.
Finally, the ivshmem-test qtest has been adapted to use the new ivhsmem
utils. Adjustments in that sense have also been made to meson.build;
also 'rt' have been removed as a lib dependency for ivhsmem-test.c.
Two lines unrelated to these changes have had their line indentation
also fixed in meson.build.
Message-ID: <20231127052024.435743-3-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
tests/qtest/ivshmem-test.c | 113 ++------------------------
tests/qtest/ivshmem-utils.c | 156 ++++++++++++++++++++++++++++++++++++
tests/qtest/ivshmem-utils.h | 56 +++++++++++++
tests/qtest/meson.build | 6 +-
4 files changed, 222 insertions(+), 109 deletions(-)
create mode 100644 tests/qtest/ivshmem-utils.c
create mode 100644 tests/qtest/ivshmem-utils.h
diff --git a/tests/qtest/ivshmem-test.c b/tests/qtest/ivshmem-test.c
index 9bf8e78df6..5ce43e2f76 100644
--- a/tests/qtest/ivshmem-test.c
+++ b/tests/qtest/ivshmem-test.c
@@ -3,17 +3,17 @@
*
* Copyright (c) 2014 SUSE LINUX Products GmbH
* Copyright (c) 2015 Red Hat, Inc.
+ * Copyright (c) 2023 Linaro Ltd.
*
* 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 "contrib/ivshmem-server/ivshmem-server.h"
+#include "ivshmem-utils.h"
#include "libqos/libqos-pc.h"
#include "libqos/libqos-spapr.h"
-#include "libqtest.h"
+
+static ServerThread thread;
#define TMPSHMSIZE (1 << 20)
static char *tmpshm;
@@ -45,13 +45,6 @@ typedef struct _IVState {
QPCIDevice *dev;
} IVState;
-enum Reg {
- INTRMASK = 0,
- INTRSTATUS = 4,
- IVPOSITION = 8,
- DOORBELL = 12,
-};
-
static const char* reg2str(enum Reg reg) {
switch (reg) {
case INTRMASK:
@@ -241,54 +234,6 @@ static void test_ivshmem_pair(void)
g_free(data);
}
-typedef struct ServerThread {
- GThread *thread;
- IvshmemServer *server;
- int pipe[2]; /* to handle quit */
-} ServerThread;
-
-static void *server_thread(void *data)
-{
- ServerThread *t = data;
- IvshmemServer *server = t->server;
-
- while (true) {
- fd_set fds;
- int maxfd, ret;
-
- FD_ZERO(&fds);
- FD_SET(t->pipe[0], &fds);
- maxfd = t->pipe[0] + 1;
-
- ivshmem_server_get_fds(server, &fds, &maxfd);
-
- ret = select(maxfd, &fds, NULL, NULL, NULL);
-
- if (ret < 0) {
- if (errno == EINTR) {
- continue;
- }
-
- g_critical("select error: %s\n", strerror(errno));
- break;
- }
- if (ret == 0) {
- continue;
- }
-
- if (FD_ISSET(t->pipe[0], &fds)) {
- break;
- }
-
- if (ivshmem_server_handle_fds(server, &fds, maxfd) < 0) {
- g_critical("ivshmem_server_handle_fds() failed\n");
- break;
- }
- }
-
- return NULL;
-}
-
static void setup_vm_with_server(IVState *s, int nvectors)
{
char *cmd;
@@ -304,27 +249,12 @@ static void setup_vm_with_server(IVState *s, int nvectors)
static void test_ivshmem_server(void)
{
- g_autoptr(GError) err = NULL;
IVState state1, state2, *s1, *s2;
- ServerThread thread;
- IvshmemServer server;
int ret, vm1, vm2;
int nvectors = 2;
guint64 end_time = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND;
- ret = ivshmem_server_init(&server, tmpserver, tmpshm, true,
- TMPSHMSIZE, nvectors,
- g_test_verbose());
- g_assert_cmpint(ret, ==, 0);
-
- ret = ivshmem_server_start(&server);
- g_assert_cmpint(ret, ==, 0);
-
- thread.server = &server;
- g_unix_open_pipe(thread.pipe, FD_CLOEXEC, &err);
- g_assert_no_error(err);
- thread.thread = g_thread_new("ivshmem-server", server_thread, &thread);
- g_assert(thread.thread != NULL);
+ test_ivshmem_server_start(&thread, tmpserver, tmpshm, nvectors);
setup_vm_with_server(&state1, nvectors);
s1 = &state1;
@@ -367,15 +297,7 @@ static void test_ivshmem_server(void)
cleanup_vm(s2);
cleanup_vm(s1);
- if (qemu_write_full(thread.pipe[1], "q", 1) != 1) {
- g_error("qemu_write_full: %s", g_strerror(errno));
- }
-
- g_thread_join(thread.thread);
-
- ivshmem_server_close(&server);
- close(thread.pipe[1]);
- close(thread.pipe[0]);
+ test_ivshmem_server_stop(&thread);
}
static void test_ivshmem_hotplug_q35(void)
@@ -454,31 +376,10 @@ static void cleanup(void)
static void abrt_handler(void *data)
{
+ test_ivshmem_server_stop(&thread);
cleanup();
}
-static gchar *mktempshm(int size, int *fd)
-{
- while (true) {
- gchar *name;
-
- name = g_strdup_printf("/qtest-%u-%u", getpid(), g_test_rand_int());
- *fd = shm_open(name, O_CREAT|O_RDWR|O_EXCL,
- S_IRWXU|S_IRWXG|S_IRWXO);
- if (*fd > 0) {
- g_assert(ftruncate(*fd, size) == 0);
- return name;
- }
-
- g_free(name);
-
- if (errno != EEXIST) {
- perror("shm_open");
- return NULL;
- }
- }
-}
-
int main(int argc, char **argv)
{
int ret, fd;
diff --git a/tests/qtest/ivshmem-utils.c b/tests/qtest/ivshmem-utils.c
new file mode 100644
index 0000000000..c2fc3463dd
--- /dev/null
+++ b/tests/qtest/ivshmem-utils.c
@@ -0,0 +1,156 @@
+/*
+ * Common utilities for testing ivshmem devices
+ *
+ * SPDX-FileCopyrightText: 2012 SUSE LINUX Products GmbH
+ * SPDX-FileCopyrightText: 2021 Red Hat, Inc.
+ * SPDX-FileCopyrightText: 2023 Linaro Ltd.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ */
+
+#include "ivshmem-utils.h"
+
+gchar *mktempshm(int size, int *fd)
+{
+ while (true) {
+ /* Relative path to the shm filesystem, e.g. '/dev/shm'. */
+ gchar *shm_rel_path;
+
+ shm_rel_path = g_strdup_printf("/ivshmem_qtest-%u-%u", getpid(),
+ g_test_rand_int());
+ *fd = shm_open(shm_rel_path, O_CREAT | O_RDWR | O_EXCL,
+ S_IRWXU | S_IRWXG | S_IRWXO);
+ if (*fd > 0) {
+ g_assert(ftruncate(*fd, size) == 0);
+ return shm_rel_path;
+ }
+
+ g_free(shm_rel_path);
+
+ if (errno != EEXIST) {
+ perror("shm_open");
+ return NULL;
+ }
+ }
+}
+
+gchar *mktempsocket(void)
+{
+ gchar *server_socket_path;
+
+ server_socket_path = g_strdup_printf("%s/ivshmem_socket_qtest-%u-%u",
+ g_get_tmp_dir(), getpid(),
+ g_test_rand_int());
+ return server_socket_path;
+}
+
+static void *server_thread(void *data)
+{
+ ServerThread *t = data;
+ IvshmemServer *server = &t->server;
+
+ while (true) {
+ fd_set fds;
+ int maxfd, ret;
+
+ FD_ZERO(&fds);
+ FD_SET(t->pipe[0], &fds);
+ maxfd = t->pipe[0] + 1;
+
+ ivshmem_server_get_fds(server, &fds, &maxfd);
+
+ ret = select(maxfd, &fds, NULL, NULL, NULL);
+
+ if (ret < 0) {
+ if (errno == EINTR) {
+ continue;
+ }
+
+ g_critical("select error: %s\n", strerror(errno));
+ break;
+ }
+ if (ret == 0) {
+ continue;
+ }
+
+ if (FD_ISSET(t->pipe[0], &fds)) {
+ break;
+ }
+
+ if (ivshmem_server_handle_fds(server, &fds, maxfd) < 0) {
+ g_critical("ivshmem_server_handle_fds() failed\n");
+ break;
+ }
+ }
+
+ return NULL;
+}
+
+void test_ivshmem_server_start(ServerThread *thread,
+ const char *server_socket_path,
+ const char *shm_rel_path, unsigned num_vectors)
+{
+ g_autoptr(GError) err = NULL;
+ int ret;
+ struct stat shm_st;
+ char *shm_path;
+
+ g_assert(thread != NULL);
+ g_assert(server_socket_path != NULL);
+ g_assert_cmpint(num_vectors, >, 0);
+ g_assert(shm_rel_path != NULL);
+
+ /*
+ * Find out shm size. shm_open() deals with relative paths but stat() needs
+ * the full path to the shm file.
+ */
+ shm_path = g_strdup_printf("/dev/shm%s", shm_rel_path);
+ ret = stat(shm_path, &shm_st);
+ g_assert_cmpint(ret, ==, 0);
+ g_assert_cmpint(shm_st.st_size, >, 0);
+
+ ret = ivshmem_server_init(&thread->server, server_socket_path, shm_rel_path,
+ true, shm_st.st_size, num_vectors, g_test_verbose());
+ g_assert_cmpint(ret, ==, 0);
+ ret = ivshmem_server_start(&thread->server);
+ g_assert_cmpint(ret, ==, 0);
+ thread->status = SERVER;
+
+ g_unix_open_pipe(thread->pipe, FD_CLOEXEC, &err);
+ g_assert_no_error(err);
+ thread->status |= PIPE;
+
+ thread->thread = g_thread_new("ivshmem-server", server_thread, thread);
+ g_assert(thread->thread != NULL);
+ thread->status |= THREAD;
+}
+
+void test_ivshmem_server_stop(ServerThread *thread)
+{
+ /*
+ * This function can be called any time on a test error/abort (e.g., it can
+ * be called from the abort handler), including from the
+ * test_ivshmem_server_start(). Therefore, the start steps (server started,
+ * pipe created, and thread created) are tracked when the server starts and
+ * then checked below accordingly for proper termination.
+ */
+
+ if (thread->status & THREAD) {
+ /* Ask to exit from thread. */
+ if (qemu_write_full(thread->pipe[1], "q", 1) != 1) {
+ g_error("qemu_write_full: %s", g_strerror(errno));
+ }
+
+ /* Wait thread to exit. */
+ g_thread_join(thread->thread);
+ }
+
+ if (thread->status & PIPE) {
+ close(thread->pipe[1]);
+ close(thread->pipe[0]);
+ }
+
+ if (thread->status & SERVER) {
+ ivshmem_server_close(&thread->server);
+ }
+}
diff --git a/tests/qtest/ivshmem-utils.h b/tests/qtest/ivshmem-utils.h
new file mode 100644
index 0000000000..c43661caac
--- /dev/null
+++ b/tests/qtest/ivshmem-utils.h
@@ -0,0 +1,56 @@
+/*
+ * Common utilities for testing ivshmem devices
+ *
+ * SPDX-FileCopyrightText: 2012 SUSE LINUX Products GmbH
+ * SPDX-FileCopyrightText: 2021 Red Hat, Inc.
+ * SPDX-FileCopyrightText: 2023 Linaro Ltd.
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ */
+
+#ifndef QTEST_IVSHMEM_UTILS_H
+#define QTEST_IVSHMEM_UTILS_H
+
+#include "qemu/osdep.h"
+#include <glib/gstdio.h>
+#include "contrib/ivshmem-server/ivshmem-server.h"
+#include "libqtest.h"
+
+enum Reg {
+ INTRMASK = 0,
+ INTRSTATUS = 4,
+ IVPOSITION = 8,
+ DOORBELL = 12,
+};
+
+enum ServerStartStatus {
+ SERVER = 1, /* Ivshmem server started */
+ THREAD = 2, /* Thread for monitoring fds created */
+ PIPE = 4, /* Pipe created */
+};
+
+typedef struct ServerThread {
+ GThread *thread;
+ IvshmemServer server;
+ /*
+ * Pipe is used to communicate with the thread, asking it to terminate on
+ * receiving 'q'.
+ */
+ int pipe[2];
+ /*
+ * Server statuses are used to keep track of thread/server/pipe start since
+ * test_ivshmem_server_stop can be called at any time on a test error,
+ * even from test_ivshmem_server_start itself, therefore, they are used for
+ * proper service termination.
+ */
+ enum ServerStartStatus status;
+} ServerThread;
+
+gchar *mktempshm(int size, int *fd);
+gchar *mktempsocket(void);
+void test_ivshmem_server_start(ServerThread *thread,
+ const char *server_socket_path,
+ const char *shm_rel_path, unsigned num_vectors);
+void test_ivshmem_server_stop(ServerThread *thread);
+
+#endif /* QTEST_IVSHMEM_UTILS_H */
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 2b89e8634b..bc6457220c 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -59,9 +59,9 @@ qtests_i386 = \
(config_all_devices.has_key('CONFIG_PVPANIC_ISA') ? ['pvpanic-test'] : []) + \
(config_all_devices.has_key('CONFIG_PVPANIC_PCI') ? ['pvpanic-pci-test'] : []) + \
(config_all_devices.has_key('CONFIG_HDA') ? ['intel-hda-test'] : []) + \
- (config_all_devices.has_key('CONFIG_I82801B11') ? ['i82801b11-test'] : []) + \
+ (config_all_devices.has_key('CONFIG_I82801B11') ? ['i82801b11-test'] : []) + \
(config_all_devices.has_key('CONFIG_IOH3420') ? ['ioh3420-test'] : []) + \
- (config_all_devices.has_key('CONFIG_LPC_ICH9') ? ['lpc-ich9-test'] : []) + \
+ (config_all_devices.has_key('CONFIG_LPC_ICH9') ? ['lpc-ich9-test'] : []) + \
(config_all_devices.has_key('CONFIG_USB_UHCI') ? ['usb-hcd-uhci-test'] : []) + \
(config_all_devices.has_key('CONFIG_USB_UHCI') and \
config_all_devices.has_key('CONFIG_USB_EHCI') ? ['usb-hcd-ehci-test'] : []) + \
@@ -319,7 +319,7 @@ qtests = {
'cdrom-test': files('boot-sector.c'),
'dbus-vmstate-test': files('migration-helpers.c') + dbus_vmstate1,
'erst-test': files('erst-test.c'),
- 'ivshmem-test': [rt, '../../contrib/ivshmem-server/ivshmem-server.c'],
+ 'ivshmem-test': ['ivshmem-utils.c', '../../contrib/ivshmem-server/ivshmem-server.c'],
'migration-test': migration_files,
'pxe-test': files('boot-sector.c'),
'qos-test': [chardev, io, qos_test_ss.apply({}).sources()],
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 5/6] tests/qtest: Reorganize common code in ivshmem-test
2024-02-22 22:22 ` [PATCH 5/6] tests/qtest: Reorganize common code in ivshmem-test Gustavo Romero
@ 2024-02-26 7:56 ` Thomas Huth
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Huth @ 2024-02-26 7:56 UTC (permalink / raw)
To: Gustavo Romero, qemu-devel, philmd
Cc: lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell
On 22/02/2024 23.22, Gustavo Romero wrote:
> This commit reorganizes the ivshmem-test qtest by moving common structs,
> functions, and code that can be utilized by other ivshmem qtests into
> two new files: ivshmem-utils.h and ivshmem-utils.c.
>
> Enum Reg, struct ServerThread, and mktempshm() have been relocated to
> these new files. Two new functions have been introduced to handle the
> ivshmem server start/stop: test_ivshmem_server_{start,stop}.
>
> To accommodate the new way for starting/stopping the ivshmem server,
> struct ServerThread now includes two new members: 'server', previously
> present but not a member of any struct; and 'status', a new member of a
> new type, ServerStartStatus, used to track and handle service
> termination properly.
>
> Additionally, a new function, mktempsocket(), has been added to help
> create a unix socket filename, similar to what mktempshm() does for the
> creation of a shm file.
>
> Finally, the ivshmem-test qtest has been adapted to use the new ivhsmem
> utils. Adjustments in that sense have also been made to meson.build;
> also 'rt' have been removed as a lib dependency for ivhsmem-test.c.
>
> Two lines unrelated to these changes have had their line indentation
> also fixed in meson.build.
>
> Message-ID: <20231127052024.435743-3-gustavo.romero@linaro.org>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
> ---
...
> diff --git a/tests/qtest/ivshmem-utils.c b/tests/qtest/ivshmem-utils.c
> new file mode 100644
> index 0000000000..c2fc3463dd
> --- /dev/null
> +++ b/tests/qtest/ivshmem-utils.c
> @@ -0,0 +1,156 @@
> +/*
> + * Common utilities for testing ivshmem devices
> + *
> + * SPDX-FileCopyrightText: 2012 SUSE LINUX Products GmbH
> + * SPDX-FileCopyrightText: 2021 Red Hat, Inc.
> + * SPDX-FileCopyrightText: 2023 Linaro Ltd.
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + */
> +
> +#include "ivshmem-utils.h"
> +
> +gchar *mktempshm(int size, int *fd)
> +{
> + while (true) {
> + /* Relative path to the shm filesystem, e.g. '/dev/shm'. */
> + gchar *shm_rel_path;
> +
> + shm_rel_path = g_strdup_printf("/ivshmem_qtest-%u-%u", getpid(),
> + g_test_rand_int());
> + *fd = shm_open(shm_rel_path, O_CREAT | O_RDWR | O_EXCL,
> + S_IRWXU | S_IRWXG | S_IRWXO);
> + if (*fd > 0) {
> + g_assert(ftruncate(*fd, size) == 0);
> + return shm_rel_path;
> + }
> +
> + g_free(shm_rel_path);
> +
> + if (errno != EEXIST) {
> + perror("shm_open");
> + return NULL;
> + }
> + }
> +}
> +
> +gchar *mktempsocket(void)
> +{
> + gchar *server_socket_path;
> +
> + server_socket_path = g_strdup_printf("%s/ivshmem_socket_qtest-%u-%u",
> + g_get_tmp_dir(), getpid(),
> + g_test_rand_int());
> + return server_socket_path;
> +}
You could simplify that to:
return g_strdup_printf("%s/ivshmem_socket_qtest-%u-%u",
g_get_tmp_dir(), getpid(),
g_test_rand_int());
Anyway:
Acked-by: Thomas Huth <thuth@redhat.com>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 6/6] tests/qtest: Add ivshmem-flat test
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
` (4 preceding siblings ...)
2024-02-22 22:22 ` [PATCH 5/6] tests/qtest: Reorganize common code in ivshmem-test Gustavo Romero
@ 2024-02-22 22:22 ` Gustavo Romero
2024-02-26 8:00 ` Thomas Huth
2024-02-28 6:29 ` [PATCH 0/6] Add ivshmem-flat device Markus Armbruster
6 siblings, 1 reply; 14+ messages in thread
From: Gustavo Romero @ 2024-02-22 22:22 UTC (permalink / raw)
To: qemu-devel, philmd
Cc: thuth, lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell, gustavo.romero
This commit adds a qtest for the ivshmem-flat device to test memory
sharing, IRQ triggering, and the memory mapped registers in the device.
Based-on: https://lists.gnu.org/archive/html/qemu-devel/2023-11/msg03176.html
Message-ID: <20231127052024.435743-4-gustavo.romero@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
tests/qtest/ivshmem-flat-test.c | 338 ++++++++++++++++++++++++++++++++
tests/qtest/meson.build | 2 +
2 files changed, 340 insertions(+)
create mode 100644 tests/qtest/ivshmem-flat-test.c
diff --git a/tests/qtest/ivshmem-flat-test.c b/tests/qtest/ivshmem-flat-test.c
new file mode 100644
index 0000000000..b6f59bba54
--- /dev/null
+++ b/tests/qtest/ivshmem-flat-test.c
@@ -0,0 +1,338 @@
+/*
+ * Inter-VM Shared Memory Flat Device qtests
+ *
+ * SPDX-FileCopyrightText: 2023 Linaro Ltd.
+ * SPDX-FileContributor: Gustavo Romero <gustavo.romero@linaro.org>
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ */
+
+#include "ivshmem-utils.h"
+
+#define IVSHMEM_FLAT_MMR_ADDR 0x400FF000
+#define IVSHMEM_FLAT_SHM_ADDR 0x40100000
+#define SHM_SIZE 131072 /* 128k */
+
+static ServerThread thread;
+
+uint32_t *shm_ptr;
+char *shm_rel_path;
+char *server_socket_path;
+
+static void cleanup(void)
+{
+ if (shm_ptr) {
+ munmap(shm_ptr, SHM_SIZE);
+ shm_ptr = NULL;
+ }
+
+ if (shm_rel_path) {
+ shm_unlink(shm_rel_path);
+ shm_rel_path = NULL;
+ }
+
+ if (server_socket_path) {
+ unlink(server_socket_path);
+ server_socket_path = NULL;
+ }
+}
+
+static void abort_handler(void *data)
+{
+ test_ivshmem_server_stop(&thread);
+ cleanup();
+}
+
+/*
+ * Check if exactly 1 positive pulse (low->high->low) on 'irq' qtest IRQ line
+ * happens. N.B.: 'irq' must be intercepted using qtest_irq_intercept_* before
+ * this function can be used on it. It returns 0 when pulse is detected,
+ * otherwise 1.
+ */
+static int test_ivshmem_flat_irq_positive_pulse(QTestState *qts, int irq)
+{
+ uint64_t num_raises = 0;
+ uint64_t num_lows = 0;
+ int attempts = 0;
+
+ while (attempts < 5) {
+ num_raises = qtest_get_irq_raised_counter(qts, 0);
+ if (num_raises) {
+ num_lows = qtest_get_irq_lowered_counter(qts, 0);
+ /* Check for exactly 1 raise and 1 low IRQ event */
+ if (num_raises == num_lows && num_lows == 1) {
+ return 0; /* Pulse detected */
+ }
+ }
+
+ g_usleep(10000);
+ attempts++;
+ }
+
+ g_message("%s: Timeout expired", __func__);
+ return 1;
+}
+
+static inline uint32_t read_reg(QTestState *qts, enum Reg reg)
+{
+ uint32_t v;
+
+ qtest_memread(qts, IVSHMEM_FLAT_MMR_ADDR + reg, &v, sizeof(v));
+
+ return v;
+}
+
+static inline void write_reg(QTestState *qts, enum Reg reg, uint32_t v)
+{
+ qtest_memwrite(qts, IVSHMEM_FLAT_MMR_ADDR + reg, &v, sizeof(v));
+}
+
+/*
+ * Setup a test VM with ivshmem-flat device attached, IRQ properly set, and
+ * connected to the ivshmem-server.
+ */
+static QTestState *setup_vm(void)
+{
+ QTestState *qts;
+ const char *cmd_line;
+
+ /*
+ * x-bus-address-{iomem,shmem} are just random addresses that don't conflict
+ * with any other address in the lm3s6965evb machine. shmem-size used is
+ * much smaller than the ivshmem server default (4 MiB) to save memory
+ * resources when testing.
+ */
+ cmd_line = g_strdup_printf("-machine lm3s6965evb "
+ "-chardev socket,path=%s,id=ivshm "
+ "-device ivshmem-flat,chardev=ivshm,"
+ "x-irq-qompath='/machine/soc/v7m/nvic/unnamed-gpio-in[0]',"
+ "x-bus-address-iomem=%#x,"
+ "x-bus-address-shmem=%#x,"
+ "shmem-size=%d",
+ server_socket_path,
+ IVSHMEM_FLAT_MMR_ADDR,
+ IVSHMEM_FLAT_SHM_ADDR,
+ SHM_SIZE);
+
+ qts = qtest_init(cmd_line);
+
+ return qts;
+}
+
+static void test_ivshmem_flat_irq(void)
+{
+ QTestState *vm_state;
+ uint16_t own_id;
+
+ vm_state = setup_vm();
+
+ qtest_irq_intercept_out_named(vm_state,
+ "/machine/peripheral-anon/device[0]",
+ "sysbus-irq");
+
+ /* IVPOSTION has the device's own ID distributed by the ivshmem-server. */
+ own_id = read_reg(vm_state, IVPOSITION);
+
+ /* Make device notify itself. */
+ write_reg(vm_state, DOORBELL, (own_id << 16) | 0 /* vector 0 */);
+
+ /*
+ * Check intercepted device's IRQ output line. 'sysbus-irq' was associated
+ * to qtest IRQ 0 when intercepted and after self notification qtest IRQ 0
+ * must be toggled by the device. The test fails if no toggling is detected.
+ */
+ g_assert(test_ivshmem_flat_irq_positive_pulse(vm_state,
+ 0 /* qtest IRQ */) == 0);
+
+ qtest_quit(vm_state);
+}
+
+static void test_ivshmem_flat_shm_write(void)
+{
+ QTestState *vm_state;
+ int num_elements, i;
+ uint32_t *data;
+
+ vm_state = setup_vm();
+
+ /* Prepare test data with random values. */
+ data = g_malloc(SHM_SIZE);
+ num_elements = SHM_SIZE / sizeof(*data);
+ for (i = 0; i < num_elements; i++) {
+ data[i] = g_test_rand_int();
+ }
+
+ /*
+ * Write test data to VM address IVSHMEM_FLAT_SHM_ADDR, where the shared
+ * memory region is located.
+ */
+ qtest_memwrite(vm_state, IVSHMEM_FLAT_SHM_ADDR, data, SHM_SIZE);
+
+ /*
+ * Since the shared memory fd is mmapped into this test process VMA at
+ * shm_ptr, every byte written by the VM in its shared memory region should
+ * also be available in the test process via shm_ptr. Thus, data in shm_ptr
+ * is compared back against the original test data.
+ */
+ for (i = 0; i < num_elements; i++) {
+ g_assert_cmpint(shm_ptr[i], ==, data[i]);
+ }
+
+ qtest_quit(vm_state);
+}
+
+static void test_ivshmem_flat_shm_read(void)
+{
+ QTestState *vm_state;
+ int num_elements, i;
+ uint32_t *data;
+ uint32_t v;
+
+ vm_state = setup_vm();
+
+ /* Prepare test data with random values. */
+ data = g_malloc(SHM_SIZE);
+ num_elements = SHM_SIZE / sizeof(*data);
+ for (i = 0; i < num_elements; i++) {
+ data[i] = g_test_rand_int();
+ }
+
+ /*
+ * Copy test data to the shared memory region so it can be read from the VM
+ * (IVSHMEM_FLAT_SHM_ADDR location).
+ */
+ memcpy(shm_ptr, data, SHM_SIZE);
+
+ /* Check data */
+ for (i = 0; i < num_elements; i++) {
+ qtest_memread(vm_state, IVSHMEM_FLAT_SHM_ADDR + i * sizeof(v), &v,
+ sizeof(v));
+ g_assert_cmpint(v, ==, data[i]);
+ }
+
+ qtest_quit(vm_state);
+}
+
+static void test_ivshmem_flat_shm_pair(void)
+{
+ QTestState *vm0_state, *vm1_state;
+ uint16_t vm0_peer_id, vm1_peer_id;
+ int num_elements, i;
+ uint32_t *data;
+ uint32_t v;
+
+ vm0_state = setup_vm();
+ vm1_state = setup_vm();
+
+ /* Get peer ID for the VM so it can be used for one notify each other. */
+ vm0_peer_id = read_reg(vm0_state, IVPOSITION);
+ vm1_peer_id = read_reg(vm1_state, IVPOSITION);
+
+ /* Observe vm1 IRQ output line first. */
+ qtest_irq_intercept_out_named(vm1_state,
+ "/machine/peripheral-anon/device[0]",
+ "sysbus-irq");
+
+ /* Notify (interrupt) VM1 from VM0. */
+ write_reg(vm0_state, DOORBELL, (vm1_peer_id << 16) | 0 /* vector 0 */);
+
+ /* Check if VM1 IRQ output line is toggled after notification from VM0. */
+ g_assert(test_ivshmem_flat_irq_positive_pulse(vm1_state,
+ 0 /* qtest IRQ */) == 0);
+
+ /* Secondly, observe VM0 IRQ output line first. */
+ qtest_irq_intercept_out_named(vm0_state,
+ "/machine/peripheral-anon/device[0]",
+ "sysbus-irq");
+
+ /* ... and do the opposite: notify (interrupt) VM0 from VM1. */
+ write_reg(vm1_state, DOORBELL, (vm0_peer_id << 16) | 0 /* vector 0 */);
+
+ /* Check if VM0 IRQ output line is toggled after notification from VM0. */
+ g_assert(test_ivshmem_flat_irq_positive_pulse(vm0_state,
+ 0 /* qtest IRQ */) == 0);
+
+ /* Prepare test data with random values. */
+ data = g_malloc(SHM_SIZE);
+ num_elements = SHM_SIZE / sizeof(*data);
+ for (i = 0; i < num_elements; i++) {
+ data[i] = g_test_rand_int();
+ }
+
+ /* Write test data on VM0. */
+ qtest_memwrite(vm0_state, IVSHMEM_FLAT_SHM_ADDR, data, SHM_SIZE);
+
+ /* Check test data on VM1. */
+ for (i = 0; i < num_elements; i++) {
+ qtest_memread(vm1_state, IVSHMEM_FLAT_SHM_ADDR + i * sizeof(v), &v,
+ sizeof(v));
+ g_assert_cmpint(v, ==, data[i]);
+ }
+
+ /* Prepare new test data with random values. */
+ for (i = 0; i < num_elements; i++) {
+ data[i] = g_test_rand_int();
+ }
+
+ /* Write test data on VM1. */
+ qtest_memwrite(vm1_state, IVSHMEM_FLAT_SHM_ADDR, data, SHM_SIZE);
+
+ /* Check test data on VM0. */
+ for (i = 0; i < num_elements; i++) {
+ qtest_memread(vm0_state, IVSHMEM_FLAT_SHM_ADDR + i * sizeof(v), &v,
+ sizeof(v));
+ g_assert_cmpint(v, ==, data[i]);
+ }
+
+ qtest_quit(vm0_state);
+ qtest_quit(vm1_state);
+}
+
+int main(int argc, char *argv[])
+{
+ int shm_fd, r;
+
+ g_test_init(&argc, &argv, NULL);
+
+ if (!qtest_has_machine("lm3s6965evb")) {
+ g_test_skip("Machine Stellaris (lm3s6965evb) not found, "
+ "skipping ivshmem-flat device test.");
+ return 0;
+ }
+
+ /* If test fails, stop server, cleanup socket and shm files. */
+ qtest_add_abrt_handler(abort_handler, NULL);
+
+ shm_rel_path = mktempshm(SHM_SIZE, &shm_fd);
+ g_assert(shm_rel_path);
+
+ /*
+ * Map shm to this test's VMA so it's possible to read/write from/to it. For
+ * VMs with the ivhsmem-flat device attached, this region will also be
+ * mapped in their own memory layout, at IVSHMEM_FLAT_SHM_ADDR (default).
+ */
+ shm_ptr = mmap(0, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
+ g_assert(shm_ptr != MAP_FAILED);
+
+ server_socket_path = mktempsocket();
+ /* It never fails, so no assert(). */
+
+ /*
+ * Currently, ivshmem-flat device only supports notification via 1 vector,
+ * i.e. vector 0.
+ */
+ test_ivshmem_server_start(&thread, server_socket_path, shm_rel_path, 1);
+
+ /* Register tests. */
+ qtest_add_func("/ivshmem-flat/irq", test_ivshmem_flat_irq);
+ qtest_add_func("/ivshmem-flat/shm-write", test_ivshmem_flat_shm_write);
+ qtest_add_func("/ivshmem-flat/shm-read", test_ivshmem_flat_shm_read);
+ qtest_add_func("/ivshmem-flat/pair", test_ivshmem_flat_shm_pair);
+
+ r = g_test_run();
+
+ test_ivshmem_server_stop(&thread);
+ cleanup();
+
+ return r;
+}
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index bc6457220c..c0468bc6e0 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -205,6 +205,7 @@ qtests_stm32l4x5 = \
'stm32l4x5_syscfg-test']
qtests_arm = \
+ (config_all_devices.has_key('CONFIG_IVSHMEM_FLAT_DEVICE') ? ['ivshmem-flat-test'] : []) + \
(config_all_devices.has_key('CONFIG_MPS2') ? ['sse-timer-test'] : []) + \
(config_all_devices.has_key('CONFIG_CMSDK_APB_DUALTIMER') ? ['cmsdk-apb-dualtimer-test'] : []) + \
(config_all_devices.has_key('CONFIG_CMSDK_APB_TIMER') ? ['cmsdk-apb-timer-test'] : []) + \
@@ -320,6 +321,7 @@ qtests = {
'dbus-vmstate-test': files('migration-helpers.c') + dbus_vmstate1,
'erst-test': files('erst-test.c'),
'ivshmem-test': ['ivshmem-utils.c', '../../contrib/ivshmem-server/ivshmem-server.c'],
+ 'ivshmem-flat-test': ['ivshmem-utils.c', '../../contrib/ivshmem-server/ivshmem-server.c'],
'migration-test': migration_files,
'pxe-test': files('boot-sector.c'),
'qos-test': [chardev, io, qos_test_ss.apply({}).sources()],
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 6/6] tests/qtest: Add ivshmem-flat test
2024-02-22 22:22 ` [PATCH 6/6] tests/qtest: Add ivshmem-flat test Gustavo Romero
@ 2024-02-26 8:00 ` Thomas Huth
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Huth @ 2024-02-26 8:00 UTC (permalink / raw)
To: Gustavo Romero, qemu-devel, philmd
Cc: lvivier, qemu-arm, alex.bennee, pbonzini, anton.kochkov,
richard.henderson, peter.maydell
On 22/02/2024 23.22, Gustavo Romero wrote:
> This commit adds a qtest for the ivshmem-flat device to test memory
> sharing, IRQ triggering, and the memory mapped registers in the device.
>
> Based-on: https://lists.gnu.org/archive/html/qemu-devel/2023-11/msg03176.html
> Message-ID: <20231127052024.435743-4-gustavo.romero@linaro.org>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
> ---
> tests/qtest/ivshmem-flat-test.c | 338 ++++++++++++++++++++++++++++++++
> tests/qtest/meson.build | 2 +
> 2 files changed, 340 insertions(+)
> create mode 100644 tests/qtest/ivshmem-flat-test.c
Acked-by: Thomas Huth <thuth@redhat.com>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/6] Add ivshmem-flat device
2024-02-22 22:22 [PATCH 0/6] Add ivshmem-flat device Gustavo Romero
` (5 preceding siblings ...)
2024-02-22 22:22 ` [PATCH 6/6] tests/qtest: Add ivshmem-flat test Gustavo Romero
@ 2024-02-28 6:29 ` Markus Armbruster
2024-04-22 16:47 ` Gustavo Romero
6 siblings, 1 reply; 14+ messages in thread
From: Markus Armbruster @ 2024-02-28 6:29 UTC (permalink / raw)
To: Gustavo Romero
Cc: qemu-devel, philmd, thuth, lvivier, qemu-arm, alex.bennee,
pbonzini, anton.kochkov, richard.henderson, peter.maydell
Gustavo Romero <gustavo.romero@linaro.org> writes:
[...]
> This patchset introduces a new device, ivshmem-flat, which is similar to the
> current ivshmem device but does not require a PCI bus. It implements the ivshmem
> status and control registers as MMRs and the shared memory as a directly
> accessible memory region in the VM memory layout. It's meant to be used on
> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a tiny
> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
> memory-constrained resource targets.
>
> The patchset includes a QTest for the ivshmem-flat device, however, it's also
> possible to experiment with it in two ways:
>
> (a) using two Cortex-M VMs running Zephyr; or
> (b) using one aarch64 VM running Linux with the ivshmem PCI device and another
> arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>
> Please note that for running the ivshmem-flat QTests the following patch, which
> is not committed to the tree yet, must be applied:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
What problem are you trying to solve with ivshmem?
Shared memory is not a solution to any communication problem, it's
merely a building block for building such solutions: you invariably have
to layer some protocol on top. What do you intend to put on top of
ivshmem?
[...]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 0/6] Add ivshmem-flat device
2024-02-28 6:29 ` [PATCH 0/6] Add ivshmem-flat device Markus Armbruster
@ 2024-04-22 16:47 ` Gustavo Romero
2024-04-23 10:39 ` Markus Armbruster
0 siblings, 1 reply; 14+ messages in thread
From: Gustavo Romero @ 2024-04-22 16:47 UTC (permalink / raw)
To: Markus Armbruster
Cc: qemu-devel, philmd, thuth, lvivier, qemu-arm, alex.bennee,
pbonzini, anton.kochkov, richard.henderson, peter.maydell,
Bill Mills
Hi Markus,
Thanks for interesting in the ivshmem-flat device.
Bill Mills (cc:ed) is the best person to answer your question,
so please find his answer below.
On 2/28/24 3:29 AM, Markus Armbruster wrote:
> Gustavo Romero <gustavo.romero@linaro.org> writes:
>
> [...]
>
>> This patchset introduces a new device, ivshmem-flat, which is similar to the
>> current ivshmem device but does not require a PCI bus. It implements the ivshmem
>> status and control registers as MMRs and the shared memory as a directly
>> accessible memory region in the VM memory layout. It's meant to be used on
>> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
>> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a tiny
>> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
>> memory-constrained resource targets.
>>
>> The patchset includes a QTest for the ivshmem-flat device, however, it's also
>> possible to experiment with it in two ways:
>>
>> (a) using two Cortex-M VMs running Zephyr; or
>> (b) using one aarch64 VM running Linux with the ivshmem PCI device and another
>> arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>>
>> Please note that for running the ivshmem-flat QTests the following patch, which
>> is not committed to the tree yet, must be applied:
>>
>> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
>
> What problem are you trying to solve with ivshmem?
>
> Shared memory is not a solution to any communication problem, it's
> merely a building block for building such solutions: you invariably have
> to layer some protocol on top. What do you intend to put on top of
> ivshmem?
Actually ivshmem is shared memory and bi-direction notifications (in this case a doorbell register and an irq).
This is the fundamental requirement for many types of communication but our interest is for the OpenAMP project [1].
All the OpenAMP project's communication is based on shared memory and bi-directional notification. Often this is on a AMP SOC with Cortex-As and Cortex-Ms or Rs. However we are now expanding into PCIe based AMP. One example of this is an x86 host computer and a PCIe card with an ARM SOC. Other examples include two systems with PCIe root complex connected via a non-transparent bridge.
The existing PCI based ivshmem lets us model these types of systems in a simple generic way without worrying about the details of the RC/EP relationship or the details of a specific non-transparent bridge. In fact the ivshmem looks to the two (or more) systems like a non-transparent bridge with its own memory (and no other memory access is allowed).
Right now we are testing this with RPMSG between two QEMU system where both systems are cortex-a53 and both running Zephyr. [2]
We will expand this by switching one of the QEMU systems to either arm64 Linux or x86 Linux.
We (and others) are also working on a generic virtio transport that will work between any two systems as long as they have shared memory and bi-directional notifications.
Now for ivshmem-flat. We want to expand this model to include MCU like CPUs and RTOS'es that don't have PCIe. We focus on Cortex-M because every open source RTOS has an existing port for one of the Cortex-M machines already in QEMU. However they don't normally pick the same one. If we added our own custom machine for this, the QEMU project would push back and even if accepted we would have to do a port for each RTOS. This would mean we would not test as many RTOSes.
The ivshmem-flat is actually a good model for what a Cortex-M based PCIe card would look like. The host system would see the connection as PCIe but to the Cortex-M it would just appear as memory, MMR's for the doorbell, and an IRQ.
So even after we have a "roll your own machine definition from a file", I expect ivshmem and ivshmem-flat to still be very useful.
[1] https://www.openampproject.org/
[2] Work in progress here: https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/zephyr/dual_qemu_ivshmem
Cheers,
Gustavo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/6] Add ivshmem-flat device
2024-04-22 16:47 ` Gustavo Romero
@ 2024-04-23 10:39 ` Markus Armbruster
2024-04-23 16:00 ` Bill Mills
0 siblings, 1 reply; 14+ messages in thread
From: Markus Armbruster @ 2024-04-23 10:39 UTC (permalink / raw)
To: Gustavo Romero
Cc: qemu-devel, philmd, thuth, lvivier, qemu-arm, alex.bennee,
pbonzini, anton.kochkov, richard.henderson, peter.maydell,
Bill Mills
Gustavo Romero <gustavo.romero@linaro.org> writes:
> Hi Markus,
>
> Thanks for interesting in the ivshmem-flat device.
>
> Bill Mills (cc:ed) is the best person to answer your question,
> so please find his answer below.
>
> On 2/28/24 3:29 AM, Markus Armbruster wrote:
>> Gustavo Romero <gustavo.romero@linaro.org> writes:
>>
>> [...]
>>
>>> This patchset introduces a new device, ivshmem-flat, which is similar to the
>>> current ivshmem device but does not require a PCI bus. It implements the ivshmem
>>> status and control registers as MMRs and the shared memory as a directly
>>> accessible memory region in the VM memory layout. It's meant to be used on
>>> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
>>> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a tiny
>>> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
>>> memory-constrained resource targets.
>>>
>>> The patchset includes a QTest for the ivshmem-flat device, however, it's also
>>> possible to experiment with it in two ways:
>>>
>>> (a) using two Cortex-M VMs running Zephyr; or
>>> (b) using one aarch64 VM running Linux with the ivshmem PCI device and another
>>> arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>>>
>>> Please note that for running the ivshmem-flat QTests the following patch, which
>>> is not committed to the tree yet, must be applied:
>>>
>>> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
>>
>> What problem are you trying to solve with ivshmem?
>>
>> Shared memory is not a solution to any communication problem, it's
>> merely a building block for building such solutions: you invariably have
>> to layer some protocol on top. What do you intend to put on top of
>> ivshmem?
>
> Actually ivshmem is shared memory and bi-direction notifications (in this case a doorbell register and an irq).
Yes, ivshmem-doorbell supports interrupts. Doesn't change my argument.
> This is the fundamental requirement for many types of communication but our interest is for the OpenAMP project [1].
>
> All the OpenAMP project's communication is based on shared memory and bi-directional notification. Often this is on a AMP SOC with Cortex-As and Cortex-Ms or Rs. However we are now expanding into PCIe based AMP. One example of this is an x86 host computer and a PCIe card with an ARM SOC. Other examples include two systems with PCIe root complex connected via a non-transparent bridge.
>
> The existing PCI based ivshmem lets us model these types of systems in a simple generic way without worrying about the details of the RC/EP relationship or the details of a specific non-transparent bridge. In fact the ivshmem looks to the two (or more) systems like a non-transparent bridge with its own memory (and no other memory access is allowed).
>
> Right now we are testing this with RPMSG between two QEMU system where both systems are cortex-a53 and both running Zephyr. [2]
>
> We will expand this by switching one of the QEMU systems to either arm64 Linux or x86 Linux.
So you want to simulate a heterogeneous machine by connecting multiple
qemu-system-FOO processes via ivshmem, correct?
> We (and others) are also working on a generic virtio transport that will work between any two systems as long as they have shared memory and bi-directional notifications.
On top of or adjacent to ivshmem?
> Now for ivshmem-flat. We want to expand this model to include MCU like CPUs and RTOS'es that don't have PCIe. We focus on Cortex-M because every open source RTOS has an existing port for one of the Cortex-M machines already in QEMU. However they don't normally pick the same one. If we added our own custom machine for this, the QEMU project would push back and even if accepted we would have to do a port for each RTOS. This would mean we would not test as many RTOSes.
>
> The ivshmem-flat is actually a good model for what a Cortex-M based PCIe card would look like. The host system would see the connection as PCIe but to the Cortex-M it would just appear as memory, MMR's for the doorbell, and an IRQ.
>
> So even after we have a "roll your own machine definition from a file", I expect ivshmem and ivshmem-flat to still be very useful.
>
> [1] https://www.openampproject.org/
> [2] Work in progress here: https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/zephyr/dual_qemu_ivshmem
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/6] Add ivshmem-flat device
2024-04-23 10:39 ` Markus Armbruster
@ 2024-04-23 16:00 ` Bill Mills
2024-04-25 11:58 ` Markus Armbruster
0 siblings, 1 reply; 14+ messages in thread
From: Bill Mills @ 2024-04-23 16:00 UTC (permalink / raw)
To: Markus Armbruster, Gustavo Romero
Cc: qemu-devel, philmd, thuth, lvivier, qemu-arm, alex.bennee,
pbonzini, anton.kochkov, richard.henderson, peter.maydell
Hi Markus,
On 4/23/24 6:39 AM, Markus Armbruster wrote:
> Gustavo Romero <gustavo.romero@linaro.org> writes:
>
>> Hi Markus,
>>
>> Thanks for interesting in the ivshmem-flat device.
>>
>> Bill Mills (cc:ed) is the best person to answer your question,
>> so please find his answer below.
>>
>> On 2/28/24 3:29 AM, Markus Armbruster wrote:
>>> Gustavo Romero <gustavo.romero@linaro.org> writes:
>>>
>>> [...]
>>>
>>>> This patchset introduces a new device, ivshmem-flat, which is similar to the
>>>> current ivshmem device but does not require a PCI bus. It implements the ivshmem
>>>> status and control registers as MMRs and the shared memory as a directly
>>>> accessible memory region in the VM memory layout. It's meant to be used on
>>>> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
>>>> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a tiny
>>>> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
>>>> memory-constrained resource targets.
>>>>
>>>> The patchset includes a QTest for the ivshmem-flat device, however, it's also
>>>> possible to experiment with it in two ways:
>>>>
>>>> (a) using two Cortex-M VMs running Zephyr; or
>>>> (b) using one aarch64 VM running Linux with the ivshmem PCI device and another
>>>> arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>>>>
>>>> Please note that for running the ivshmem-flat QTests the following patch, which
>>>> is not committed to the tree yet, must be applied:
>>>>
>>>> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
>>>
>>> What problem are you trying to solve with ivshmem?
>>>
>>> Shared memory is not a solution to any communication problem, it's
>>> merely a building block for building such solutions: you invariably have
>>> to layer some protocol on top. What do you intend to put on top of
>>> ivshmem?
>>
>> Actually ivshmem is shared memory and bi-direction notifications (in this case a doorbell register and an irq).
>
> Yes, ivshmem-doorbell supports interrupts. Doesn't change my argument.
>
>> This is the fundamental requirement for many types of communication but our interest is for the OpenAMP project [1].
>>
>> All the OpenAMP project's communication is based on shared memory and bi-directional notification. Often this is on a AMP SOC with Cortex-As and Cortex-Ms or Rs. However we are now expanding into PCIe based AMP. One example of this is an x86 host computer and a PCIe card with an ARM SOC. Other examples include two systems with PCIe root complex connected via a non-transparent bridge.
>>
>> The existing PCI based ivshmem lets us model these types of systems in a simple generic way without worrying about the details of the RC/EP relationship or the details of a specific non-transparent bridge. In fact the ivshmem looks to the two (or more) systems like a non-transparent bridge with its own memory (and no other memory access is allowed).
>>
>> Right now we are testing this with RPMSG between two QEMU system where both systems are cortex-a53 and both running Zephyr. [2]
>>
>> We will expand this by switching one of the QEMU systems to either arm64 Linux or x86 Linux.
>
> So you want to simulate a heterogeneous machine by connecting multiple
> qemu-system-FOO processes via ivshmem, correct?
An AMP SOC is one use case. A PCIe card with an embedded Cortex-M would
be another.
>
>> We (and others) are also working on a generic virtio transport that will work between any two systems as long as they have shared memory and bi-directional notifications.
>
> On top of or adjacent to ivshmem?
>
On top of ivshmem. It is not the only use case but it is an important one.
I just gave a talk on this subject at EOSS. If you would like to look
at the slides they are here:
https://sched.co/1aBFm
Thanks,
Bill
>> Now for ivshmem-flat. We want to expand this model to include MCU like CPUs and RTOS'es that don't have PCIe. We focus on Cortex-M because every open source RTOS has an existing port for one of the Cortex-M machines already in QEMU. However they don't normally pick the same one. If we added our own custom machine for this, the QEMU project would push back and even if accepted we would have to do a port for each RTOS. This would mean we would not test as many RTOSes.
>>
>> The ivshmem-flat is actually a good model for what a Cortex-M based PCIe card would look like. The host system would see the connection as PCIe but to the Cortex-M it would just appear as memory, MMR's for the doorbell, and an IRQ.
>>
>> So even after we have a "roll your own machine definition from a file", I expect ivshmem and ivshmem-flat to still be very useful.
>>
>> [1] https://www.openampproject.org/
>> [2] Work in progress here: https://github.com/OpenAMP/openamp-system-reference/tree/main/examples/zephyr/dual_qemu_ivshmem
>
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/6] Add ivshmem-flat device
2024-04-23 16:00 ` Bill Mills
@ 2024-04-25 11:58 ` Markus Armbruster
0 siblings, 0 replies; 14+ messages in thread
From: Markus Armbruster @ 2024-04-25 11:58 UTC (permalink / raw)
To: Bill Mills
Cc: Gustavo Romero, qemu-devel, philmd, thuth, lvivier, qemu-arm,
alex.bennee, pbonzini, anton.kochkov, richard.henderson,
peter.maydell
Bill Mills <bill.mills@linaro.org> writes:
> Hi Markus,
>
> On 4/23/24 6:39 AM, Markus Armbruster wrote:
>> Gustavo Romero <gustavo.romero@linaro.org> writes:
>>
>>> Hi Markus,
>>>
>>> Thanks for interesting in the ivshmem-flat device.
>>>
>>> Bill Mills (cc:ed) is the best person to answer your question,
>>> so please find his answer below.
>>>
>>> On 2/28/24 3:29 AM, Markus Armbruster wrote:
>>>> Gustavo Romero <gustavo.romero@linaro.org> writes:
>>>>
>>>> [...]
>>>>
>>>>> This patchset introduces a new device, ivshmem-flat, which is similar to the
>>>>> current ivshmem device but does not require a PCI bus. It implements the ivshmem
>>>>> status and control registers as MMRs and the shared memory as a directly
>>>>> accessible memory region in the VM memory layout. It's meant to be used on
>>>>> machines like those with Cortex-M MCUs, which usually lack a PCI bus, e.g.,
>>>>> lm3s6965evb and mps2-an385. Additionally, it has the benefit of requiring a tiny
>>>>> 'device driver,' which is helpful on some RTOSes, like Zephyr, that run on
>>>>> memory-constrained resource targets.
>>>>>
>>>>> The patchset includes a QTest for the ivshmem-flat device, however, it's also
>>>>> possible to experiment with it in two ways:
>>>>>
>>>>> (a) using two Cortex-M VMs running Zephyr; or
>>>>> (b) using one aarch64 VM running Linux with the ivshmem PCI device and another
>>>>> arm (Cortex-M) VM running Zephyr with the new ivshmem-flat device.
>>>>>
>>>>> Please note that for running the ivshmem-flat QTests the following patch, which
>>>>> is not committed to the tree yet, must be applied:
>>>>>
>>>>> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03176.html
>>>>
>>>> What problem are you trying to solve with ivshmem?
>>>>
>>>> Shared memory is not a solution to any communication problem, it's
>>>> merely a building block for building such solutions: you invariably have
>>>> to layer some protocol on top. What do you intend to put on top of
>>>> ivshmem?
>>>
>>> Actually ivshmem is shared memory and bi-direction notifications (in this case a doorbell register and an irq).
>>
>> Yes, ivshmem-doorbell supports interrupts. Doesn't change my argument.
>>
>>> This is the fundamental requirement for many types of communication but our interest is for the OpenAMP project [1].
>>>
>>> All the OpenAMP project's communication is based on shared memory and bi-directional notification. Often this is on a AMP SOC with Cortex-As and Cortex-Ms or Rs. However we are now expanding into PCIe based AMP. One example of this is an x86 host computer and a PCIe card with an ARM SOC. Other examples include two systems with PCIe root complex connected via a non-transparent bridge.
>>>
>>> The existing PCI based ivshmem lets us model these types of systems in a simple generic way without worrying about the details of the RC/EP relationship or the details of a specific non-transparent bridge. In fact the ivshmem looks to the two (or more) systems like a non-transparent bridge with its own memory (and no other memory access is allowed).
>>>
>>> Right now we are testing this with RPMSG between two QEMU system where both systems are cortex-a53 and both running Zephyr. [2]
>>>
>>> We will expand this by switching one of the QEMU systems to either arm64 Linux or x86 Linux.
>> So you want to simulate a heterogeneous machine by connecting multiple
>> qemu-system-FOO processes via ivshmem, correct?
>
> An AMP SOC is one use case. A PCIe card with an embedded Cortex-M would be another.
>
>>
>>> We (and others) are also working on a generic virtio transport that will work between any two systems as long as they have shared memory and bi-directional notifications.
>>
>> On top of or adjacent to ivshmem?
>
> On top of ivshmem. It is not the only use case but it is an important one.
Interesting.
> I just gave a talk on this subject at EOSS. If you would like to look at the slides they are here:
> https://sched.co/1aBFm
The talk's abstract:
AMP Virtio: A New Virto Transport for AMP Systems, with Focus on
Zephyr, Linux, and Xen
Asymmetric multiprocessing systems are common in automotive,
Industrial, and mobile markets and are entering the data center
market as well. The OpenAMP project strives to make AMP systems
easier and more standards based. The OpenAMP project is working on
a new Virtio transport layer that can be used between cores that do
not share a hypervisor. Example systems include: * AMP SOCs running
running Linux on Cortex-A and Zephyr on Cortex-M, * x86 and Arm
systems connected via PCIe, both running Linux. AMP Virtio can also
be used in Xen and other hypervisors to reduce worse case latency
and increase freedom of interference (FFI). These aspects are
critical in real-time and functionally safe systems. This
presentation will cover:
* Why Virtio for AMP systems
* What are the problems with the existing virtio transports for AMP
systems
* Outline of the transport proposal
* Prototype software for Zephyr, Linux, and Xen
* Show various topologies and use cases for Device and Driver
placement
* Show portability to other RTOSes and hypervisors.
You're interested in systems that contain multiple cores. You want to
create a virtio transport to let these cores talk to each other.
Let's talk physical hardware. The transport needs to go over some kind
of device. The device could be pretty smart and provide the virtio
transport, or it could be really dumb and provide just enough to let
software running on the core implement the virtio transport. What do
you have in mind?
You need QEMU to emulate one or more of the devices you have in mind.
Note: emulation is about the guest-facing part of the QEMU device model.
We'll get to the host-facing part in a minute.
Smart device: we know how to emulate virtio devices with various
connectors, such as PCI, CCW, MMIO.
Dumb device: ivshmem-doorbell could serve as a virtual dumb device.
Note that a physical ivshmem would be a bad idea; it's design is rather
poor. Is this why you're interested in ivshmem?
As is, ivshmem-doorbell comes with a PCI connector. You want an MMIO
connector. Fair enough.
Once you have an actual dumb physical device, you're likely better off
emulating that instead of approximating it with ivshmem.
Approximating could still be useful as a stopgap.
I sidestepped an important problem so far: the "asymmetric" in AMP.
When your asymmetric system contains cores with different architectures,
QEMU can't emulate the entire system, because qemu-system-TARGET can
only emulate cores with achitecture TARGET.
I guess you want to work around this limitation by running multiple
qemu-system-TARGETs. Trouble is you then need to connect them somehow.
ivshmem's host-facing part can connect its qemu-system-TARGET to other
processes, including other qemu-system-TARGETs, and the TARGETs need not
be identical. Correct?
What if we had a qemu-system that wasn't limited to a single
architecture? Would you still want to run multiple connected instances
then, or would you simply model your asymmetric system in a single one?
[...]
^ permalink raw reply [flat|nested] 14+ messages in thread