[Qemu-devel] [PATCH 0/9] Add platform bus

[Qemu-devel] [PATCH 0/9] Add platform bus

[Alexander Graf]

Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
device creation world of QEMU. Devices on these were modeled as SysBus devices
which can only be instantiated in machine files, not through -device.

Why is that so?

Well, SysBus is trying to be incredibly generic. It allows you to plug any
interrupt sender into any other interrupt receiver. It allows you to map
a device's memory regions into any other random memory region. All of that
only works from C code.

But do we need that level of complexity for normal devices usually? In a
normal platform world (SoCs, PV machines) we have a flat memory layout we
can plug our device memory into. We also have a flat IRQ model where we
can plug our device IRQs into.

This platform bus creates a simple bus that models the easy world. It allows
for dynamic device creation through -device. A device may or may not explictly
request to be mapped at a specific IRQ and/or memory address. If no explicit
mapping is requested, platform devices just get mapped at convenient places.

This goes hand in hand with automatic device tree generation. When QEMU
places devices somewhere and also generates a device tree to tell the guest
where exactly those devices are, we close the cycle and everyone knows
everything and lives happily ever after.

The actual pressing issue this solves is that today it's impossible to spawn
serial ports from the command line. With this patch set, it's possible to
do so. But it lays the groundwork for much more...

Alex

Alexander Graf (9):
  PlatBus: Add Platform Bus
  PlatBus: Add abstract Platform Device
  PlatBus: Add Sysbus/Platform bridge device
  PlatBus: Hook up into Makefile system
  PPC: Add platform bus to the default compile set
  PlatBus: Add serial-platbus device
  PPC: Add PlatBus Serial to default configs
  PPC: E500: Spawn PlatBus bridge for ppce500 machine
  PPC: E500: Add PlatBus device tree walker

 default-configs/ppc-softmmu.mak    |   2 +
 default-configs/ppc64-softmmu.mak  |   2 +
 default-configs/ppcemb-softmmu.mak |   2 +
 hw/Makefile.objs                   |   1 +
 hw/char/Makefile.objs              |   1 +
 hw/char/serial-platbus.c           | 100 +++++++++++++++++++++++
 hw/platbus/Makefile.objs           |   1 +
 hw/platbus/bridge.c                |  64 +++++++++++++++
 hw/platbus/device.c                | 162 +++++++++++++++++++++++++++++++++++++
 hw/platbus/platbus.c               | 107 ++++++++++++++++++++++++
 hw/ppc/e500.c                      |  75 ++++++++++++++++-
 hw/ppc/e500.h                      |   1 +
 hw/ppc/e500plat.c                  |   1 +
 include/hw/char/serial-platbus.h   |  56 +++++++++++++
 include/hw/platbus/bridge.h        |  32 ++++++++
 include/hw/platbus/device.h        | 102 +++++++++++++++++++++++
 include/hw/platbus/platbus.h       |  86 ++++++++++++++++++++
 17 files changed, 791 insertions(+), 4 deletions(-)
 create mode 100644 hw/char/serial-platbus.c
 create mode 100644 hw/platbus/Makefile.objs
 create mode 100644 hw/platbus/bridge.c
 create mode 100644 hw/platbus/device.c
 create mode 100644 hw/platbus/platbus.c
 create mode 100644 include/hw/char/serial-platbus.h
 create mode 100644 include/hw/platbus/bridge.h
 create mode 100644 include/hw/platbus/device.h
 create mode 100644 include/hw/platbus/platbus.h

-- 
1.8.1.4

[Qemu-devel] [PATCH 1/9] PlatBus: Add Platform Bus

[Alexander Graf]

The platform bus is a very simple bus, similar to SysBus. However it has
a linear IRQ range that platform devices can attach to. It also provdes
mechanisms to dynamically place IO regions.

This patch implements the bus logic itself.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/platbus/platbus.c         | 107 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/platbus/platbus.h |  86 ++++++++++++++++++++++++++++++++++
 2 files changed, 193 insertions(+)
 create mode 100644 hw/platbus/platbus.c
 create mode 100644 include/hw/platbus/platbus.h

diff --git a/hw/platbus/platbus.c b/hw/platbus/platbus.c
new file mode 100644
index 0000000..769eb5d
--- /dev/null
+++ b/hw/platbus/platbus.c
@@ -0,0 +1,107 @@
+/*
+ * Generic platform bus with dynamic IRQ and IO placement
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ *
+ * The platform bus is a very simple bus, similar to SysBus. However it has
+ * a linear IRQ range that platform devices can attach to. It also provdes
+ * mechanisms to dynamically place IO regions.
+ *
+ * Hence platform bus devices can be easily instantiated using -device from
+ * the command line.
+ */
+
+#include "qemu-common.h"
+#include "hw/platbus/platbus.h"
+
+int platbus_map_irq(PlatBusState *s, uint32_t *irqn, qemu_irq *irq)
+{
+    if (*irqn == (uint32_t)PLATBUS_DYNAMIC) {
+        /* Find the first available IRQ */
+        *irqn = find_first_zero_bit(s->used_irqs, PLATBUS_MAX_IRQ);
+    }
+
+    if ((*irqn >= PLATBUS_MAX_IRQ) || test_and_set_bit(*irqn, s->used_irqs)) {
+        hw_error("PlatBus: IRQ %d is already allocated or no free IRQ left",
+                 *irqn);
+    }
+
+    *irq = s->irqs[*irqn];
+
+    return 0;
+}
+
+void platbus_add_irq(PlatBusState *s, uint32_t irqn)
+{
+    clear_bit(irqn, s->used_irqs);
+}
+
+int platbus_map_region(PlatBusState *s, uint64_t *addr, MemoryRegion *mem)
+{
+    uint64_t size = memory_region_size(mem);
+    uint64_t size_pages = (size + ((1 << 12) - 1)) >> 12;
+    int page;
+    int i;
+
+    page = *addr >> 12;
+    if (*addr == (uint64_t)PLATBUS_DYNAMIC) {
+        uint64_t size_pages_align;
+
+        /* Align the region to at least its own size granularity */
+        if (is_power_of_2(size_pages)) {
+            size_pages_align = size_pages;
+        } else {
+            size_pages_align = pow2floor(size_pages) << 1;
+        }
+
+        /* Find the first available region that fits */
+        page = bitmap_find_next_zero_area(s->used_mem, PLATBUS_HOLE_PAGES, 0,
+                                          size_pages, size_pages_align);
+
+        *addr = (uint64_t)page << 12;
+    }
+
+    if (page >= PLATBUS_HOLE_PAGES || test_bit(page, s->used_mem) ||
+        (find_next_bit(s->used_mem, PLATBUS_HOLE_PAGES, page) < size_pages)) {
+        hw_error("PlatBus: Memory [%"PRIx64":%"PRIx64" is already allocated or "
+                 "no slot left", *addr, size);
+    }
+
+    for (i = page; i < (page + size_pages); i++) {
+        set_bit(i, s->used_mem);
+    }
+
+    memory_region_add_subregion(&s->mem, *addr, mem);
+
+    return 0;
+}
+
+static void platbus_init(Object *obj)
+{
+    PlatBusState *s = PLAT_BUS(obj);
+
+    QTAILQ_INIT(&s->devices);
+    bitmap_fill(s->used_irqs, PLATBUS_MAX_IRQ);
+    memory_region_init(&s->mem, NULL, "platbus", PLATBUS_HOLE);
+}
+
+static const TypeInfo platbus_type_info = {
+    .name = TYPE_PLAT_BUS,
+    .parent = TYPE_BUS,
+    .instance_size = sizeof(PlatBusState),
+    .instance_init = platbus_init,
+};
+
+static void platbus_register_types(void)
+{
+    type_register_static(&platbus_type_info);
+}
+
+type_init(platbus_register_types)
diff --git a/include/hw/platbus/platbus.h b/include/hw/platbus/platbus.h
new file mode 100644
index 0000000..d260fb8
--- /dev/null
+++ b/include/hw/platbus/platbus.h
@@ -0,0 +1,86 @@
+/*
+ * Generic platform bus with dynamic IRQ and IO placement
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ */
+
+#ifndef QEMU_HW_PLATBUS_PLATBUS_H
+#define QEMU_HW_PLATBUS_PLATBUS_H
+
+#include "qemu-common.h"
+#include "hw/qdev.h"
+#include "qemu/bitmap.h"
+/* for QDEV_MAX_IRQ */
+#include "hw/sysbus.h"
+
+#define PLATBUS_MAX_IRQ QDEV_MAX_IRQ
+#define PLATBUS_DYNAMIC -1LL
+#define PLATBUS_HOLE (128ULL * 1024 * 1024) /* 128 MB */
+#define PLATBUS_HOLE_PAGES (PLATBUS_HOLE >> 12)
+
+#define TYPE_PLAT_BUS "platbus"
+#define PLAT_BUS(obj) OBJECT_CHECK(PlatBusState, (obj), TYPE_PLAT_BUS)
+
+typedef struct PlatBusState {
+    /*< private >*/
+    BusState parent_obj;
+    qemu_irq irqs[PLATBUS_MAX_IRQ];
+    DECLARE_BITMAP(used_irqs, PLATBUS_MAX_IRQ);
+    DECLARE_BITMAP(used_mem, PLATBUS_HOLE_PAGES);
+    /*< public >*/
+
+    QTAILQ_HEAD(, PlatBusDeviceState) devices;
+    MemoryRegion mem;
+} PlatBusState;
+
+/**
+ * platbus_map_region:
+ * @s: Bus to map the region to
+ * @addr: Pointer to the offset inside the platform bus address range we want to
+ *        map to. Should be PLATBUS_DYNAMIC if the bus is supposed to give us an
+ *        address. Gets written back with the actually mapped address.
+ * @mem: Pointer to a properly initialized MemoryRegion which should get mapped
+ *       into the platform bus's address space. Does not get modified.
+ *
+ * Tell the platform bus to map a device's memory region into the platform bus's
+ * address range.
+ *
+ * Returns: 0 on success. Negative values on error.
+ */
+int platbus_map_region(PlatBusState *s, uint64_t *addr, MemoryRegion *mem);
+
+/**
+ * platbus_map_region:
+ * @s: Bus to map the IRQ to
+ * @irqn: Pointer to the IRQ inside the platform bus IRQ range we want to
+ *        map to. Should be PLATBUS_DYNAMIC if the bus is supposed to give us an
+ *        IRQ number. Gets written back with the actually mapped IRQ.
+ * @irq: Pointer to a qemu_irq field. Gets populated with a real qemu_irq when
+ *       the mapping gets successfully established.
+ *
+ * Tell the platform bus to map a device's IRQ into the platform bus's IRQ range.
+ *
+ * Returns: 0 on success. Negative values on error.
+ */
+int platbus_map_irq(PlatBusState *s, uint32_t *irqn, qemu_irq *irq);
+
+/**
+ * platbus_add_irq:
+ * @s: Bus to map the IRQ to
+ * @irqn: IRQ number that gets declared valid
+ *
+ * Tell the platform bus that one of its internal IRQ lines was successfully
+ * populated with a usable qemu_irq object.
+ *
+ * Returns: 0 on success. Negative values on error.
+ */
+void platbus_add_irq(PlatBusState *s, uint32_t irqn);
+
+#endif /* !QEMU_HW_PLATBUS_PLATBUS_H */
-- 
1.8.1.4

[Qemu-devel] [PATCH 2/9] PlatBus: Add abstract Platform Device

[Alexander Graf]

This patch adds an abstract platform device class. Real platform devices
should use this as their parent class.

It manages IO memory regions and IRQ ranges for the actual device.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/platbus/device.c         | 162 ++++++++++++++++++++++++++++++++++++++++++++
 include/hw/platbus/device.h | 102 ++++++++++++++++++++++++++++
 2 files changed, 264 insertions(+)
 create mode 100644 hw/platbus/device.c
 create mode 100644 include/hw/platbus/device.h

diff --git a/hw/platbus/device.c b/hw/platbus/device.c
new file mode 100644
index 0000000..74ba11b
--- /dev/null
+++ b/hw/platbus/device.c
@@ -0,0 +1,162 @@
+/*
+ * Platform Device that can connect to a Platform Bus
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ *
+ *
+ * This is an abstract platform device, so you really only want to use it
+ * as parent class for platform devices.
+ *
+ * It ensures that all boilerplate is properly abstracted away from children
+ * and consistent across devices.
+ *
+ * When instantiating a platform device you can optionally always specify 2 qdev
+ * properties which otherwise get populated automatically:
+ *
+ *  regions: Offsets in the platbus hole the device's memory regions get mapped
+ *           to.
+ *  irqs: IRQ pins in the linear platbus IRQ range the device's IRQs get mapped
+ *           to.
+ */
+
+#include "qemu-common.h"
+#include "hw/platbus/platbus.h"
+#include "hw/platbus/device.h"
+
+static int realize_regions(PlatBusDeviceState *s, PlatBusState *bus,
+                           Error **errp)
+{
+    uint64_t *addrs = g_new(uint64_t, s->num_regions);
+    int r, i;
+
+    /* get our memory regions */
+    for (i = 0; i < s->num_regions; i++) {
+        if (s->num_plat_region_addrs > i) {
+            /* user defined region */
+            addrs[i] = s->plat_region_addrs[i];
+        } else {
+            /* dynamically allocated region */
+            addrs[i] = PLATBUS_DYNAMIC;
+        }
+
+        r = platbus_map_region(bus, &addrs[i], s->regions[i]);
+        if (r) {
+            error_setg(errp, "PlatBus Device: Could not map region at %" PRIx64,
+                       addrs[i]);
+            return -1;
+        }
+    }
+
+    /* update our region list, so that we can see it with info qtree */
+    s->plat_region_addrs = addrs;
+    s->num_plat_region_addrs = s->num_regions;
+
+    return 0;
+}
+
+static int realize_irqs(PlatBusDeviceState *s, PlatBusState *bus, Error **errp)
+{
+    uint32_t *irqs = g_new(uint32_t, s->num_irqs);
+    int r, i;
+
+    /* get our IRQs */
+    for (i = 0; i < s->num_irqs; i++) {
+        if (s->num_plat_irqs > i) {
+            /* user defined IRQ */
+            irqs[i] = s->plat_irqs[i];
+        } else {
+            /* dynamically allocated IRQ */
+            irqs[i] = PLATBUS_DYNAMIC;
+        }
+
+        r = platbus_map_irq(bus, &irqs[i], s->irqs[i]);
+        if (r) {
+            error_setg(errp, "PlatBus Device: Could not map IRQ %d", irqs[i]);
+            return -1;
+        }
+    }
+
+    /* update our IRQ list, so that we can see it with info qtree */
+    s->plat_irqs = irqs;
+    s->num_plat_irqs = s->num_irqs;
+
+    return 0;
+}
+
+static void platbus_device_realize(DeviceState *dev, Error **errp)
+{
+    PlatBusDeviceState *s = PLATBUS_DEVICE(dev);
+    PlatBusState *bus = PLAT_BUS(qdev_get_parent_bus(dev));
+
+    /* Register memory regions and IRQs */
+    if (realize_regions(s, bus, errp) || realize_irqs(s, bus, errp)) {
+        return;
+    }
+
+    /* Tell the bus that we're here */
+    QTAILQ_INSERT_TAIL(&bus->devices, s, next);
+}
+
+static Property platbus_device_properties[] = {
+    /* memory regions for a device */
+    DEFINE_PROP_ARRAY("regions", PlatBusDeviceState, num_plat_region_addrs,
+                      plat_region_addrs, qdev_prop_uint64, uint64_t),
+    /* interrupts for a device */
+    DEFINE_PROP_ARRAY("irqs", PlatBusDeviceState, num_plat_irqs,
+                      plat_irqs, qdev_prop_uint32, uint32_t),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void platbus_device_class_init(ObjectClass *oc, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(oc);
+
+    dc->realize = platbus_device_realize;
+    dc->bus_type = TYPE_PLAT_BUS;
+    dc->props = platbus_device_properties;
+}
+
+static const TypeInfo platbus_device_type_info = {
+    .name = TYPE_PLATBUS_DEVICE,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(PlatBusDeviceState),
+    .abstract = true,
+    .class_init = platbus_device_class_init,
+};
+
+
+static void device_register_types(void)
+{
+    type_register_static(&platbus_device_type_info);
+}
+
+type_init(device_register_types)
+
+/******** public methods *********/
+
+void platbus_device_set_irqs_array(PlatBusDeviceState *dev, int n,
+                                   qemu_irq **irqs)
+{
+    qemu_irq **irqs_v = g_new(qemu_irq *, n);
+    memcpy(irqs_v, irqs, sizeof(qemu_irq *) * n);
+
+    dev->irqs = irqs_v;
+    dev->num_irqs = n;
+}
+
+void platbus_device_set_regions_array(PlatBusDeviceState *dev, int n,
+                                      MemoryRegion **regions)
+{
+    MemoryRegion **regions_v = g_new(MemoryRegion *, n);
+    memcpy(regions_v, regions, sizeof(MemoryRegion *) * n);
+
+    dev->regions = regions_v;
+    dev->num_regions = n;
+}
diff --git a/include/hw/platbus/device.h b/include/hw/platbus/device.h
new file mode 100644
index 0000000..f8cbc56
--- /dev/null
+++ b/include/hw/platbus/device.h
@@ -0,0 +1,102 @@
+/*
+ * Generic platform bus with dynamic IRQ and IO placement
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ */
+
+#ifndef QEMU_HW_PLATBUS_DEVICE_H
+#define QEMU_HW_PLATBUS_DEVICE_H
+
+#include "qemu-common.h"
+#include "hw/qdev.h"
+
+#define TYPE_PLATBUS_DEVICE "platbus-device"
+#define PLATBUS_DEVICE(obj) OBJECT_CHECK(PlatBusDeviceState, (obj), TYPE_PLATBUS_DEVICE)
+
+typedef struct PlatBusDeviceState {
+    /*< private >*/
+
+    DeviceState parent_obj;
+    QTAILQ_ENTRY(PlatBusDeviceState) next;
+
+    /* these get set by children through platbus_device_set_xxx() */
+    uint32_t num_regions;
+    MemoryRegion **regions;
+    uint32_t num_irqs;
+    qemu_irq **irqs;
+
+    /*< public >*/
+
+    /* these get set by the user though qdev parameters */
+    uint32_t num_plat_region_addrs;
+    uint64_t *plat_region_addrs;
+    uint32_t num_plat_irqs;
+    uint32_t *plat_irqs;
+} PlatBusDeviceState;
+
+
+/******** public methods *********/
+
+
+/**
+ * platbus_device_set_regions:
+ * @dev: Parent PlatBusDevice object
+ * @...: Pointers to properly initialized MemoryRegions
+ *
+ * Call this as PlatBusDevice child to tell your parent the location of your
+ * already initialized memory region objects.
+ */
+#define platbus_device_set_regions(dev, ...)                                   \
+    do {                                                                       \
+        MemoryRegion *regions[] = { __VA_ARGS__ };                             \
+        platbus_device_set_regions_array(dev, ARRAY_SIZE(regions), regions);   \
+    } while (0)
+
+/**
+ * platbus_device_set_regions_array:
+ * @dev: Parent PlatBusDevice object
+ * @n: Number of regions
+ * @regions: Pointers to properly initialized MemoryRegions
+ *
+ * Call this as PlatBusDevice child to tell your parent the location of your
+ * already initialized memory region objects.
+ */
+void platbus_device_set_regions_array(PlatBusDeviceState *dev, int n,
+                                      MemoryRegion **regions);
+
+/**
+ * platbus_device_set_irqs:
+ * @dev: Parent PlatBusDevice object
+ * @...: Pointers to qemu_irq fields
+ *
+ * Call this as PlatBusDevice child to tell your parent the location of your
+ * qemu_irq fields. These fields will get populated once the bus is fully
+ * initialized.
+ */
+#define platbus_device_set_irqs(dev, ...)                                      \
+    do {                                                                       \
+        qemu_irq *irqs[] = { __VA_ARGS__ };                                    \
+        platbus_device_set_irqs_array(dev, ARRAY_SIZE(irqs), irqs);            \
+    } while (0)
+
+/**
+ * platbus_device_set_irqs_array:
+ * @dev: Parent PlatBusDevice object
+ * @n: Number of irqs
+ * @regions: Pointers to qemu_irq fields
+ *
+ * Call this as PlatBusDevice child to tell your parent the location of your
+ * qemu_irq fields. These fields will get populated once the bus is fully
+ * initialized.
+ */
+void platbus_device_set_irqs_array(PlatBusDeviceState *dev, int n,
+                                   qemu_irq **irqs);
+
+#endif /* !QEMU_HW_PLATBUS_DEVICE_H */
-- 
1.8.1.4

[Qemu-devel] [PATCH 3/9] PlatBus: Add Sysbus/Platform bridge device

[Alexander Graf]

We have to be able to plug our platform bus into an existing system somehow.
To achieve this, we add a sysbus <-> platbus bridge device that maps an
arbitrary number of IRQ lines to a self-contained linear platform IRQ range.

It also provides a memory region that is the parent region for all platform
devices that get created below this bus.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/platbus/bridge.c         | 64 +++++++++++++++++++++++++++++++++++++++++++++
 include/hw/platbus/bridge.h | 32 +++++++++++++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 hw/platbus/bridge.c
 create mode 100644 include/hw/platbus/bridge.h

diff --git a/hw/platbus/bridge.c b/hw/platbus/bridge.c
new file mode 100644
index 0000000..356d254
--- /dev/null
+++ b/hw/platbus/bridge.c
@@ -0,0 +1,64 @@
+/*
+ * Sysbus to Platform bus bridge device
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ *
+ * This bridge device allows you to plug a platform bus into your existing
+ * system bus.
+ */
+
+#include "qemu-common.h"
+#include "hw/platbus/bridge.h"
+
+static void platbus_bridge_realize(DeviceState *dev, Error **errp)
+{
+    SysBusDevice *d = SYS_BUS_DEVICE(dev);
+    PlatBusBridgeState *s = PLATBUS_BRIDGE(dev);
+    int i;
+
+    /* Create platform bus */
+    qbus_create_inplace(&s->bus.parent_obj, TYPE_PLAT_BUS, dev, NULL);
+
+    /* Wire up all platbus IRQs to sysbus IRQs. */
+    for (i = 0; i < s->nr_irqs; i++) {
+        sysbus_init_irq(d, &s->bus.irqs[i]);
+        platbus_add_irq(&s->bus, i);
+    }
+
+    /* Advertise our platbus memory hole to sysbus. Through this a guest OS
+       can access platbus devices */
+    sysbus_init_mmio(d, &s->bus.mem);
+}
+
+static Property platbus_bridge_properties[] = {
+    DEFINE_PROP_UINT32("nr_irqs", PlatBusBridgeState, nr_irqs, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void serial_platbus_class_init(ObjectClass *oc, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(oc);
+    dc->props = platbus_bridge_properties;
+    dc->realize = platbus_bridge_realize;
+}
+
+static const TypeInfo platbus_bridge_type_info = {
+    .name = TYPE_PLATBUS_BRIDGE,
+    .parent = TYPE_SYS_BUS_DEVICE,
+    .instance_size = sizeof(PlatBusBridgeState),
+    .class_init    = serial_platbus_class_init,
+};
+
+static void platbus_bridge_register_types(void)
+{
+    type_register_static(&platbus_bridge_type_info);
+}
+
+type_init(platbus_bridge_register_types)
diff --git a/include/hw/platbus/bridge.h b/include/hw/platbus/bridge.h
new file mode 100644
index 0000000..4d31fcb
--- /dev/null
+++ b/include/hw/platbus/bridge.h
@@ -0,0 +1,32 @@
+/*
+ * Generic platform bus with dynamic IRQ and IO placement
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Authors: Alexander Graf,   <agraf@suse.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of  the GNU General  Public License as published by
+ * the Free Software Foundation;  either version 2 of the  License, or
+ * (at your option) any later version.
+ */
+
+#ifndef QEMU_HW_PLATBUS_BRIDGE_H
+#define QEMU_HW_PLATBUS_BRIDGE_H
+
+#include "platbus.h"
+#include "hw/sysbus.h"
+
+#define TYPE_PLATBUS_BRIDGE "platbus-bridge"
+#define PLATBUS_BRIDGE(obj) OBJECT_CHECK(PlatBusBridgeState, (obj), TYPE_PLATBUS_BRIDGE)
+
+typedef struct PlatBusBridgeState {
+    /*< private >*/
+    SysBusDevice parent_obj;
+    /*< public >*/
+
+    PlatBusState bus;
+    uint32_t nr_irqs;
+} PlatBusBridgeState;
+
+#endif /* !QEMU_HW_PLATBUS_BRIDGE_H */
-- 
1.8.1.4

[Qemu-devel] [PATCH 4/9] PlatBus: Hook up into Makefile system

[Alexander Graf]

Hook up the platform bus helpers into our Makefile system, so that they
get compiled.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/Makefile.objs         | 1 +
 hw/platbus/Makefile.objs | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 hw/platbus/Makefile.objs

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 0243d6a..8535563 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -18,6 +18,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += net/
 devices-dirs-$(CONFIG_SOFTMMU) += nvram/
 devices-dirs-$(CONFIG_SOFTMMU) += pci/
 devices-dirs-$(CONFIG_PCI) += pci-bridge/ pci-host/
+devices-dirs-$(CONFIG_PLATBUS) += platbus/
 devices-dirs-$(CONFIG_SOFTMMU) += scsi/
 devices-dirs-$(CONFIG_SOFTMMU) += sd/
 devices-dirs-$(CONFIG_SOFTMMU) += ssi/
diff --git a/hw/platbus/Makefile.objs b/hw/platbus/Makefile.objs
new file mode 100644
index 0000000..73daee6
--- /dev/null
+++ b/hw/platbus/Makefile.objs
@@ -0,0 +1 @@
+common-obj-$(CONFIG_PLATBUS) += platbus.o device.o bridge.o
-- 
1.8.1.4

[Qemu-devel] [PATCH 5/9] PPC: Add platform bus to the default compile set

[Alexander Graf]

On e500 we will enable platform bus support, so make sure we always compile
it in on PPC targets.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 default-configs/ppc-softmmu.mak    | 1 +
 default-configs/ppc64-softmmu.mak  | 1 +
 default-configs/ppcemb-softmmu.mak | 1 +
 3 files changed, 3 insertions(+)

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 73e4cc5..f080fc0 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -44,5 +44,6 @@ CONFIG_XILINX_ETHLITE=y
 CONFIG_OPENPIC=y
 CONFIG_E500=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
+CONFIG_PLATBUS=y
 # For PReP
 CONFIG_MC146818RTC=y
diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak
index 6d1933b..40251b8 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -44,6 +44,7 @@ CONFIG_XILINX_ETHLITE=y
 CONFIG_OPENPIC=y
 CONFIG_PSERIES=y
 CONFIG_E500=y
+CONFIG_PLATBUS=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
 # For pSeries
 CONFIG_XICS=$(CONFIG_PSERIES)
diff --git a/default-configs/ppcemb-softmmu.mak b/default-configs/ppcemb-softmmu.mak
index e3b5e50..79e21ea 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak
@@ -38,6 +38,7 @@ CONFIG_XILINX=y
 CONFIG_XILINX_ETHLITE=y
 CONFIG_OPENPIC=y
 CONFIG_E500=y
+CONFIG_PLATBUS=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
 # For PReP
 CONFIG_MC146818RTC=y
-- 
1.8.1.4

[Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device

[Alexander Graf]

We want to be able to spawn a serial console on the platform bus. Create
a small platbus wrapper device very similar to the ISA one.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/char/Makefile.objs            |   1 +
 hw/char/serial-platbus.c         | 100 +++++++++++++++++++++++++++++++++++++++
 include/hw/char/serial-platbus.h |  56 ++++++++++++++++++++++
 3 files changed, 157 insertions(+)
 create mode 100644 hw/char/serial-platbus.c
 create mode 100644 include/hw/char/serial-platbus.h

diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index f8f3dbc..777796c 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_ESCC) += escc.o
 common-obj-$(CONFIG_PARALLEL) += parallel.o
 common-obj-$(CONFIG_PL011) += pl011.o
 common-obj-$(CONFIG_SERIAL) += serial.o serial-isa.o
+common-obj-$(CONFIG_SERIAL_PLATBUS) += serial-platbus.o
 common-obj-$(CONFIG_SERIAL_PCI) += serial-pci.o
 common-obj-$(CONFIG_VIRTIO) += virtio-console.o
 common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
diff --git a/hw/char/serial-platbus.c b/hw/char/serial-platbus.c
new file mode 100644
index 0000000..ee3019c
--- /dev/null
+++ b/hw/char/serial-platbus.c
@@ -0,0 +1,100 @@
+/*
+ * QEMU 16550A UART emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2008 Citrix Systems, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "hw/char/serial.h"
+#include "hw/char/serial-platbus.h"
+#include "hw/platbus/platbus.h"
+#include "hw/platbus/device.h"
+
+static void serial_platbus_realizefn(DeviceState *dev, Error **errp)
+{
+    PlatBusSerialClass *psc = PLATBUS_SERIAL_GET_CLASS(dev);
+    PlatBusSerialState *p = PLATBUS_SERIAL(dev);
+    SerialState *s = &p->state;
+
+    /* super() */
+    psc->parent_realize(dev, errp);
+
+    /* Initialize serial port */
+    s->baudbase = 115200;
+    serial_realize_core(s, errp);
+}
+
+static void serial_platbus_init(Object *obj)
+{
+    PlatBusSerialState *p = PLATBUS_SERIAL(obj);
+    SerialState *s = &p->state;
+    PlatBusDeviceState *pdev = &p->parent_obj;
+
+    /* Initialize static data */
+    memory_region_init_io(&s->io, OBJECT(p), &serial_io_ops, s, "serial", 8);
+
+    /* Populate parent fields */
+    platbus_device_set_irqs(pdev, &s->irq);
+    platbus_device_set_regions(pdev, &s->io);
+}
+
+static const VMStateDescription vmstate_platbus_serial = {
+    .name = "serial",
+    .version_id = 3,
+    .minimum_version_id = 2,
+    .fields = (VMStateField[]) {
+        VMSTATE_STRUCT(state, PlatBusSerialState, 0, vmstate_serial, SerialState),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+static Property serial_platbus_properties[] = {
+    DEFINE_PROP_CHR("chardev",   PlatBusSerialState, state.chr),
+    DEFINE_PROP_UINT32("wakeup", PlatBusSerialState, state.wakeup, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void serial_platbus_class_init(ObjectClass *oc, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(oc);
+    PlatBusSerialClass *psc = PLATBUS_SERIAL_CLASS(oc);
+
+    psc->parent_realize = dc->realize;
+    dc->realize = serial_platbus_realizefn;
+    dc->vmsd = &vmstate_platbus_serial;
+    dc->props = serial_platbus_properties;
+}
+
+static const TypeInfo serial_platbus_info = {
+    .name          = TYPE_PLATBUS_SERIAL,
+    .parent        = TYPE_PLATBUS_DEVICE,
+    .instance_size = sizeof(PlatBusSerialState),
+    .instance_init = serial_platbus_init,
+    .class_init    = serial_platbus_class_init,
+    .class_size    = sizeof(PlatBusSerialClass),
+};
+
+static void serial_register_types(void)
+{
+    type_register_static(&serial_platbus_info);
+}
+
+type_init(serial_register_types)
diff --git a/include/hw/char/serial-platbus.h b/include/hw/char/serial-platbus.h
new file mode 100644
index 0000000..182ab77
--- /dev/null
+++ b/include/hw/char/serial-platbus.h
@@ -0,0 +1,56 @@
+/*
+ * QEMU 16550A UART emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2008 Citrix Systems, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#ifndef HW_CHAR_SERIAL_PLATBUS_H
+#define HW_CHAR_SERIAL_PLATBUS_H
+
+#include "hw/char/serial.h"
+#include "hw/platbus/device.h"
+
+#define TYPE_PLATBUS_SERIAL "platbus-serial"
+#define PLATBUS_SERIAL(obj) OBJECT_CHECK(PlatBusSerialState, (obj), \
+                                         TYPE_PLATBUS_SERIAL)
+
+typedef struct PlatBusSerialState {
+    /*< private >*/
+    PlatBusDeviceState parent_obj;
+    /*< public >*/
+
+    SerialState state;
+} PlatBusSerialState;
+
+#define PLATBUS_SERIAL_CLASS(class) \
+    OBJECT_CLASS_CHECK(PlatBusSerialClass, (class), TYPE_PLATBUS_SERIAL)
+#define PLATBUS_SERIAL_GET_CLASS(obj) \
+    OBJECT_GET_CLASS(PlatBusSerialClass, (obj), TYPE_PLATBUS_SERIAL)
+
+typedef struct PlatBusSerialClass {
+    /*< private >*/
+    DeviceClass parent_class;
+    /*< public >*/
+
+    DeviceRealize parent_realize;
+} PlatBusSerialClass;
+
+#endif /* !HW_CHAR_SERIAL_PLATBUS_H */
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device

[Peter Maydell]

On 22 July 2013 18:50, Alexander Graf <agraf@suse.de> wrote:
> We want to be able to spawn a serial console on the platform bus. Create
> a small platbus wrapper device very similar to the ISA one.

Why not use virtio-console?

-- PMM

Re: [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device

[Alexander Graf]

On 22.07.2013, at 20:26, Peter Maydell wrote:

> On 22 July 2013 18:50, Alexander Graf <agraf@suse.de> wrote:
>> We want to be able to spawn a serial console on the platform bus. Create
>> a small platbus wrapper device very similar to the ISA one.
> 
> Why not use virtio-console?

Because eventually we want -nodefaults not generate any UARTs and only create them through -device. Guests expect /dev/ttySx device nodes for their serial ports.


Alex

Re: [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device

[Scott Wood]

On 07/22/2013 01:56:32 PM, Alexander Graf wrote:
> 
> On 22.07.2013, at 20:26, Peter Maydell wrote:
> 
> > On 22 July 2013 18:50, Alexander Graf <agraf@suse.de> wrote:
> >> We want to be able to spawn a serial console on the platform bus.  
> Create
> >> a small platbus wrapper device very similar to the ISA one.
> >
> > Why not use virtio-console?
> 
> Because eventually we want -nodefaults not generate any UARTs and  
> only create them through -device. Guests expect /dev/ttySx device  
> nodes for their serial ports.

Plus, it's nice to have debug output from early on, rather than having  
to wait until PCI is up and running.

-Scott

Re: [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device

[Peter Maydell]

On 24 July 2013 21:16, Scott Wood <scottwood@freescale.com> wrote:
> Plus, it's nice to have debug output from early on, rather than having to
> wait until PCI is up and running.

It would be nice if the device tree had bindings for
"you can find your emergency serial port here"...

-- PMM

[Qemu-devel] [PATCH 7/9] PPC: Add PlatBus Serial to default configs

[Alexander Graf]

We support the platform bus, so we also support platbus serial devices. Enable
the respective config option.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 default-configs/ppc-softmmu.mak    | 1 +
 default-configs/ppc64-softmmu.mak  | 1 +
 default-configs/ppcemb-softmmu.mak | 1 +
 3 files changed, 3 insertions(+)

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index f080fc0..eaedd6a 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -45,5 +45,6 @@ CONFIG_OPENPIC=y
 CONFIG_E500=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
 CONFIG_PLATBUS=y
+CONFIG_SERIAL_PLATBUS=y
 # For PReP
 CONFIG_MC146818RTC=y
diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak
index 40251b8..51fbcb8 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -45,6 +45,7 @@ CONFIG_OPENPIC=y
 CONFIG_PSERIES=y
 CONFIG_E500=y
 CONFIG_PLATBUS=y
+CONFIG_SERIAL_PLATBUS=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
 # For pSeries
 CONFIG_XICS=$(CONFIG_PSERIES)
diff --git a/default-configs/ppcemb-softmmu.mak b/default-configs/ppcemb-softmmu.mak
index 79e21ea..1f3e807 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak
@@ -39,6 +39,7 @@ CONFIG_XILINX_ETHLITE=y
 CONFIG_OPENPIC=y
 CONFIG_E500=y
 CONFIG_PLATBUS=y
+CONFIG_SERIAL_PLATBUS=y
 CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
 # For PReP
 CONFIG_MC146818RTC=y
-- 
1.8.1.4

[Qemu-devel] [PATCH 8/9] PPC: E500: Spawn PlatBus bridge for ppce500 machine

[Alexander Graf]

With the PV ppce500 we don't have to adhere to real hardware constraints,
but can instead layout the physical address space any way we like it.

So we can also add our fancy new platform bus to it. Through this we add
enablement to spawn platform devices with -M ppce500.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/ppc/e500.c     | 21 +++++++++++++++++++++
 hw/ppc/e500.h     |  1 +
 hw/ppc/e500plat.c |  1 +
 3 files changed, 23 insertions(+)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 904a1e7..8548622 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -36,6 +36,8 @@
 #include "exec/address-spaces.h"
 #include "qemu/host-utils.h"
 #include "hw/pci-host/ppce500.h"
+#include "hw/platbus/bridge.h"
+#include "hw/platbus/device.h"
 
 #define EPAPR_MAGIC                (0x45504150)
 #define BINARY_DEVICE_TREE_FILE    "mpc8544ds.dtb"
@@ -48,6 +50,10 @@
 
 #define RAM_SIZES_ALIGN            (64UL << 20)
 
+#define E500_PLATBUS_BASE          0xF0000000ULL
+#define E500_PLATBUS_FIRST_IRQ     5
+#define E500_PLATBUS_NUM_IRQS      10
+
 /* TODO: parameterize */
 #define MPC8544_CCSRBAR_BASE       0xE0000000ULL
 #define MPC8544_CCSRBAR_SIZE       0x00100000ULL
@@ -731,6 +737,21 @@ void ppce500_init(PPCE500Params *params)
     /* Register spinning region */
     sysbus_create_simple("e500-spin", MPC8544_SPIN_BASE, NULL);
 
+    /* Platform Bus */
+    if (params->has_platbus) {
+        dev = qdev_create(NULL, "platbus-bridge");
+        dev->id = "platbus";
+        qdev_prop_set_uint32(dev, "nr_irqs", E500_PLATBUS_NUM_IRQS);
+        qdev_init_nofail(dev);
+
+        s = SYS_BUS_DEVICE(dev);
+        for (i = 0; i < E500_PLATBUS_NUM_IRQS; i++) {
+            sysbus_connect_irq(s, i, mpic[E500_PLATBUS_FIRST_IRQ + i]);
+        }
+        memory_region_add_subregion(address_space_mem, E500_PLATBUS_BASE,
+                                    sysbus_mmio_get_region(s, 0));
+    }
+
     /* Load kernel. */
     if (params->kernel_filename) {
         kernel_size = load_uimage(params->kernel_filename, &entry,
diff --git a/hw/ppc/e500.h b/hw/ppc/e500.h
index 226c93d..1ed1f7e 100644
--- a/hw/ppc/e500.h
+++ b/hw/ppc/e500.h
@@ -18,6 +18,7 @@ typedef struct PPCE500Params {
     void (*fixup_devtree)(struct PPCE500Params *params, void *fdt);
 
     int mpic_version;
+    bool has_platbus;
 } PPCE500Params;
 
 void ppce500_init(PPCE500Params *params);
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index c852995..a373936 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -47,6 +47,7 @@ static void e500plat_init(QEMUMachineInitArgs *args)
         .pci_nr_slots = PCI_SLOT_MAX - 1,
         .fixup_devtree = e500plat_fixup_devtree,
         .mpic_version = OPENPIC_MODEL_FSL_MPIC_42,
+        .has_platbus = true,
     };
 
     /* Older KVM versions don't support EPR which breaks guests when we announce
-- 
1.8.1.4

[Qemu-devel] [PATCH 9/9] PPC: E500: Add PlatBus device tree walker

[Alexander Graf]

We need to tell the guest where devices are in its physical address space
and how they are connected to IRQ lines.

This patch adds a simply PlatBus walker that generates device tree chunks
for every device it finds. The only device it knows how to handle today
is a serial port, but that may change in the future.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/ppc/e500.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 8548622..e0d0a19 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -38,6 +38,7 @@
 #include "hw/pci-host/ppce500.h"
 #include "hw/platbus/bridge.h"
 #include "hw/platbus/device.h"
+#include "hw/char/serial-platbus.h"
 
 #define EPAPR_MAGIC                (0x45504150)
 #define BINARY_DEVICE_TREE_FILE    "mpc8544ds.dtb"
@@ -108,7 +109,7 @@ static uint32_t *pci_map_create(void *fdt, uint32_t mpic, int first_slot,
 }
 
 static void dt_serial_create(void *fdt, unsigned long long offset,
-                             const char *soc, const char *mpic,
+                             const char *soc, const char *mpic, int irq,
                              const char *alias, int idx, bool defcon)
 {
     char ser[128];
@@ -120,7 +121,7 @@ static void dt_serial_create(void *fdt, unsigned long long offset,
     qemu_devtree_setprop_cells(fdt, ser, "reg", offset, 0x100);
     qemu_devtree_setprop_cell(fdt, ser, "cell-index", idx);
     qemu_devtree_setprop_cell(fdt, ser, "clock-frequency", 0);
-    qemu_devtree_setprop_cells(fdt, ser, "interrupts", 42, 2);
+    qemu_devtree_setprop_cells(fdt, ser, "interrupts", irq, 2);
     qemu_devtree_setprop_phandle(fdt, ser, "interrupt-parent", mpic);
     qemu_devtree_setprop_string(fdt, "/aliases", alias, ser);
 
@@ -129,6 +130,42 @@ static void dt_serial_create(void *fdt, unsigned long long offset,
     }
 }
 
+static void platbus_create_devtree(DeviceState *dev, void *fdt,
+                                   const char *node, uint64_t addr,
+                                   const char *mpic, int irq_start,
+                                   int nr_irqs)
+{
+    PlatBusBridgeState *s = PLATBUS_BRIDGE(dev);
+    BusChild *kid;
+    const char platcomp[] = "qemu,platbus\0simple-bus";
+    int serial_idx = 2;
+
+    qemu_devtree_setprop(fdt, node, "compatible", platcomp, sizeof(platcomp));
+    qemu_devtree_setprop_string(fdt, node, "device_type", "platbus");
+
+    /* Our platbus hole is less than 32bit big, so 1 cell is enough for address
+       and size */
+    qemu_devtree_setprop_cells(fdt, node, "#size-cells", 1);
+    qemu_devtree_setprop_cells(fdt, node, "#address-cells", 1);
+    qemu_devtree_setprop_cells(fdt, node, "ranges", 0, addr >> 32, addr,
+                               PLATBUS_HOLE);
+
+    qemu_devtree_setprop_phandle(fdt, node, "interrupt-parent", mpic);
+
+    QTAILQ_FOREACH(kid, &s->bus.parent_obj.children, sibling) {
+        DeviceState *dev = kid->child;
+        PlatBusDeviceState *pbd = PLATBUS_DEVICE(dev);
+
+        if (PLATBUS_SERIAL(dev)) {
+            char *alias = g_strdup_printf("serial%d", serial_idx);
+            dt_serial_create(fdt, pbd->plat_region_addrs[0], node,
+                             mpic, irq_start + pbd->plat_irqs[0], alias,
+                             serial_idx, serial_idx == 0);
+            serial_idx++;
+        }
+    }
+}
+
 static int ppce500_load_device_tree(PPCE500Params *params,
                                     hwaddr addr,
                                     hwaddr initrd_base,
@@ -136,6 +173,7 @@ static int ppce500_load_device_tree(PPCE500Params *params,
                                     bool dry_run)
 {
     CPUPPCState *env = first_cpu->env_ptr;
+    DeviceState *platbus;
     int ret = -1;
     uint64_t mem_reg_property[] = { 0, cpu_to_be64(params->ram_size) };
     int fdt_size;
@@ -310,9 +348,9 @@ static int ppce500_load_device_tree(PPCE500Params *params,
      * devices in reverse order to the dt.
      */
     dt_serial_create(fdt, MPC8544_SERIAL1_REGS_OFFSET,
-                     soc, mpic, "serial1", 1, false);
+                     soc, mpic, 42, "serial1", 1, false);
     dt_serial_create(fdt, MPC8544_SERIAL0_REGS_OFFSET,
-                     soc, mpic, "serial0", 0, true);
+                     soc, mpic, 42, "serial0", 0, true);
 
     snprintf(gutil, sizeof(gutil), "%s/global-utilities@%llx", soc,
              MPC8544_UTIL_OFFSET);
@@ -367,6 +405,14 @@ static int ppce500_load_device_tree(PPCE500Params *params,
     qemu_devtree_setprop_cell(fdt, pci, "#address-cells", 3);
     qemu_devtree_setprop_string(fdt, "/aliases", "pci0", pci);
 
+    platbus = qdev_find_recursive(sysbus_get_default(), "platbus");
+    if (platbus) {
+        qemu_devtree_add_subnode(fdt, "/platbus");
+        platbus_create_devtree(platbus, fdt, "/platbus", E500_PLATBUS_BASE,
+                               mpic, E500_PLATBUS_FIRST_IRQ,
+                               E500_PLATBUS_NUM_IRQS);
+    }
+
     params->fixup_devtree(params, fdt);
 
     if (toplevel_compat) {
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 22 July 2013 18:50, Alexander Graf <agraf@suse.de> wrote:
> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
> device creation world of QEMU. Devices on these were modeled as SysBus devices
> which can only be instantiated in machine files, not through -device.
>
> Why is that so?

Because you can't as a user of this sort of hardware
plug in an extra serial port to a SoC, because there's just nowhere
to plug it in. So why should it be possible to plug an extra
serial port into the QEMU model of the SoC? And why should
the user of QEMU have to know very low hardware level detail
like what a particular devboard's IRQ and memory map are?

One thing that is missing is the ability to nicely support
configuring the devices the board model creates (-global doesn't
really cut it).

> Well, SysBus is trying to be incredibly generic. It allows you to plug any
> interrupt sender into any other interrupt receiver. It allows you to map
> a device's memory regions into any other random memory region. All of that
> only works from C code.
>
> But do we need that level of complexity for normal devices usually? In a
> normal platform world (SoCs, PV machines) we have a flat memory layout we
> can plug our device memory into. We also have a flat IRQ model where we
> can plug our device IRQs into.
>
> This platform bus creates a simple bus that models the easy world. It allows
> for dynamic device creation through -device. A device may or may not explictly
> request to be mapped at a specific IRQ and/or memory address. If no explicit
> mapping is requested, platform devices just get mapped at convenient places.

I think this is going in the wrong direction. We should (longterm)
be getting rid of sysbus in favour of having enough QOM support
for a device to provide both IRQ lines and memory regions as QOM
properties or links or whatever they're called. Sysbus only exists
because when it was put in the qdev infrastructure implicitly assumed
that everything had to be on a bus. It still exists today just because
it's the easy way to declare that you have some IRQ lines and
memory regions that can be wired up by the device creator.

> This goes hand in hand with automatic device tree generation. When QEMU
> places devices somewhere and also generates a device tree to tell the guest
> where exactly those devices are, we close the cycle and everyone knows
> everything and lives happily ever after.

Autogenerating device trees is going to require more than this,
for example where do we figure out how to specify clocks and
voltage regulators for each device? (And more generally how
do you handle adding whatever random extra info the kernel of
the day decides it needs?)

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Alexander Graf]

On 22.07.2013, at 20:21, Peter Maydell wrote:

> On 22 July 2013 18:50, Alexander Graf <agraf@suse.de> wrote:
>> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>> device creation world of QEMU. Devices on these were modeled as SysBus devices
>> which can only be instantiated in machine files, not through -device.
>> 
>> Why is that so?
> 
> Because you can't as a user of this sort of hardware
> plug in an extra serial port to a SoC, because there's just nowhere
> to plug it in. So why should it be possible to plug an extra
> serial port into the QEMU model of the SoC? And why should
> the user of QEMU have to know very low hardware level detail
> like what a particular devboard's IRQ and memory map are?

He doesn't. That's the point.

> 
> One thing that is missing is the ability to nicely support
> configuring the devices the board model creates (-global doesn't
> really cut it).
> 
>> Well, SysBus is trying to be incredibly generic. It allows you to plug any
>> interrupt sender into any other interrupt receiver. It allows you to map
>> a device's memory regions into any other random memory region. All of that
>> only works from C code.
>> 
>> But do we need that level of complexity for normal devices usually? In a
>> normal platform world (SoCs, PV machines) we have a flat memory layout we
>> can plug our device memory into. We also have a flat IRQ model where we
>> can plug our device IRQs into.
>> 
>> This platform bus creates a simple bus that models the easy world. It allows
>> for dynamic device creation through -device. A device may or may not explictly
>> request to be mapped at a specific IRQ and/or memory address. If no explicit
>> mapping is requested, platform devices just get mapped at convenient places.
> 
> I think this is going in the wrong direction. We should (longterm)
> be getting rid of sysbus in favour of having enough QOM support
> for a device to provide both IRQ lines and memory regions as QOM
> properties or links or whatever they're called.

This is basically what this patch set does, just by trimming down the problem to a bearable set. "Links" become PlatBus device properties. That makes it easy to model everything.

> Sysbus only exists
> because when it was put in the qdev infrastructure implicitly assumed
> that everything had to be on a bus. It still exists today just because
> it's the easy way to declare that you have some IRQ lines and
> memory regions that can be wired up by the device creator.
> 
>> This goes hand in hand with automatic device tree generation. When QEMU
>> places devices somewhere and also generates a device tree to tell the guest
>> where exactly those devices are, we close the cycle and everyone knows
>> everything and lives happily ever after.
> 
> Autogenerating device trees is going to require more than this,
> for example where do we figure out how to specify clocks and
> voltage regulators for each device? (And more generally how
> do you handle adding whatever random extra info the kernel of
> the day decides it needs?)

Device trees usually come from firmware. ARM is screwed up in that sense, since kernel developers randomly extend and modify device trees to their needs. So for ARM you'd also need a machine option to tell the generator which kernel flavor of the day you want to generate the device tree for.


Alex

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Paolo Bonzini]

Il 22/07/2013 20:21, Peter Maydell ha scritto:
>> > Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>> > device creation world of QEMU. Devices on these were modeled as SysBus devices
>> > which can only be instantiated in machine files, not through -device.
>> >
>> > Why is that so?
> Because you can't as a user of this sort of hardware
> plug in an extra serial port to a SoC, because there's just nowhere
> to plug it in. So why should it be possible to plug an extra
> serial port into the QEMU model of the SoC?

And why exactly should QEMU be limited to modeling an existing SoC?

Perhaps the user is not working with an existing SoC.  They are working
with with IP building blocks that they can combine the way they prefer,
and they haven't yet made up their mind on the exact set of devices
they'll have.  (because not all the world is a PC, but then not all the
non-PC world is ARM either).

Perhaps the user is working on kernel support for device tree / ACPI,
wants to test many device combinations, and does not want to touch C
code in order to do that.

Perhaps the user can plug daughterboards that connect to the SoC and add
an extra serial port, visible as yet another MMIO device.

> And why should
> the user of QEMU have to know very low hardware level detail
> like what a particular devboard's IRQ and memory map are?

Of course in some scenarios the user of QEMU doesn't need them, but
there are many kinds of users...

Paolo

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 22/07/2013 20:21, Peter Maydell ha scritto:
>>> > Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>>> > device creation world of QEMU. Devices on these were modeled as SysBus devices
>>> > which can only be instantiated in machine files, not through -device.
>>> >
>>> > Why is that so?
>> Because you can't as a user of this sort of hardware
>> plug in an extra serial port to a SoC, because there's just nowhere
>> to plug it in. So why should it be possible to plug an extra
>> serial port into the QEMU model of the SoC?
>
> And why exactly should QEMU be limited to modeling an existing SoC?
>
> Perhaps the user is not working with an existing SoC.  They are working
> with with IP building blocks that they can combine the way they prefer,
> and they haven't yet made up their mind on the exact set of devices
> they'll have.  (because not all the world is a PC, but then not all the
> non-PC world is ARM either).

This sounds like (a) a good thing (b) something that will
turn into an incredible incomprehensible mess if we try
to specify it on the command line. Why would we want to do that?

That is, you're arguing for a scripting/config language for
putting together board models so you don't have to write them
in C. That's a good thing, but not what this patch series is doing.

> Perhaps the user is working on kernel support for device tree / ACPI,
> wants to test many device combinations, and does not want to touch C
> code in order to do that.
>
> Perhaps the user can plug daughterboards that connect to the SoC and add
> an extra serial port, visible as yet another MMIO device.

Pluggable daughterboards should be implemented by actually
defining the bus/socket that exists between the mainboard
and the daughterboard, so you could say -device my-daughterboard
and have it plug in to the mainboard.

-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Paolo Bonzini]

Il 23/07/2013 14:22, Peter Maydell ha scritto:
> On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 22/07/2013 20:21, Peter Maydell ha scritto
>>> you can't as a user of this sort of hardware
>>> plug in an extra serial port to a SoC, because there's just nowhere
>>> to plug it in. So why should it be possible to plug an extra
>>> serial port into the QEMU model of the SoC?
>>
>> And why exactly should QEMU be limited to modeling an existing SoC?
>>
>> Perhaps the user is not working with an existing SoC.  They are working
>> with with IP building blocks that they can combine the way they prefer,
>> and they haven't yet made up their mind on the exact set of devices
>> they'll have.  (because not all the world is a PC, but then not all the
>> non-PC world is ARM either).
> 
> This sounds like (a) a good thing (b) something that will
> turn into an incredible incomprehensible mess if we try
> to specify it on the command line. Why would we want to do that?

It is an incomprehensible mess on the command line, but it is actually
quite fine if you use "-readconfig" instead.

It will not support for "-serial" and similar "shortcut" options, but
they aren't necessary.  PCI-enabled or paravirtual boards have been able
to run for years now with "-nodefaults" and only "-device" options.

> That is, you're arguing for a scripting/config language for
> putting together board models so you don't have to write them
> in C. That's a good thing, but not what this patch series is doing.

It is, modulo lack of support for "-serial" and similar "shortcut"
options.  Gluing those still requires C code (for PC as well).

>> Perhaps the user is working on kernel support for device tree / ACPI,
>> wants to test many device combinations, and does not want to touch C
>> code in order to do that.
>>
>> Perhaps the user can plug daughterboards that connect to the SoC and add
>> an extra serial port, visible as yet another MMIO device.
> 
> Pluggable daughterboards should be implemented by actually
> defining the bus/socket that exists between the mainboard
> and the daughterboard, so you could say -device my-daughterboard
> and have it plug in to the mainboard.

The bus might just be the processor's data bus + the interrupt
controller's pins, basically the same as sysbus.

In fact, the main thing I dislike about Alex's patch is adding a new bus
instead of making sysbus devices "just work" as pluggable devices.

Paolo

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 23 July 2013 13:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 23/07/2013 14:22, Peter Maydell ha scritto:
>> On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 22/07/2013 20:21, Peter Maydell ha scritto
>>>> you can't as a user of this sort of hardware
>>>> plug in an extra serial port to a SoC, because there's just nowhere
>>>> to plug it in. So why should it be possible to plug an extra
>>>> serial port into the QEMU model of the SoC?
>>>
>>> And why exactly should QEMU be limited to modeling an existing SoC?
>>>
>>> Perhaps the user is not working with an existing SoC.  They are working
>>> with with IP building blocks that they can combine the way they prefer,
>>> and they haven't yet made up their mind on the exact set of devices
>>> they'll have.  (because not all the world is a PC, but then not all the
>>> non-PC world is ARM either).
>>
>> This sounds like (a) a good thing (b) something that will
>> turn into an incredible incomprehensible mess if we try
>> to specify it on the command line. Why would we want to do that?
>
> It is an incomprehensible mess on the command line, but it is actually
> quite fine if you use "-readconfig" instead.

Well, the justification for this whole new bus appears to be
"so you can easily just add a new device on the command line".

>>> Perhaps the user can plug daughterboards that connect to the SoC and add
>>> an extra serial port, visible as yet another MMIO device.
>>
>> Pluggable daughterboards should be implemented by actually
>> defining the bus/socket that exists between the mainboard
>> and the daughterboard, so you could say -device my-daughterboard
>> and have it plug in to the mainboard.
>
> The bus might just be the processor's data bus + the interrupt
> controller's pins, basically the same as sysbus.

Yes, we should have easy support for defining a pluggable
bus as a collection of pins.

> In fact, the main thing I dislike about Alex's patch is adding a new bus
> instead of making sysbus devices "just work" as pluggable devices.

Agreed, more or less. Actually I'd rather sysbus devices
went away -- the requirement for interrupt and GPIO and
memory regions to all be defined as single arrays (so you
have to know what interrupt line 3 happens to be, and
that memory region 1 is the registers, and so on) is
pretty unfriendly. We should be able to define all these
as named connections.

-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Paolo Bonzini]

Il 23/07/2013 14:40, Peter Maydell ha scritto:
> On 23 July 2013 13:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 23/07/2013 14:22, Peter Maydell ha scritto:
>>> On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> Il 22/07/2013 20:21, Peter Maydell ha scritto
>>>>> you can't as a user of this sort of hardware
>>>>> plug in an extra serial port to a SoC, because there's just nowhere
>>>>> to plug it in. So why should it be possible to plug an extra
>>>>> serial port into the QEMU model of the SoC?
>>>>
>>>> And why exactly should QEMU be limited to modeling an existing SoC?
>>>>
>>>> Perhaps the user is not working with an existing SoC.  They are working
>>>> with with IP building blocks that they can combine the way they prefer,
>>>> and they haven't yet made up their mind on the exact set of devices
>>>> they'll have.  (because not all the world is a PC, but then not all the
>>>> non-PC world is ARM either).
>>>
>>> This sounds like (a) a good thing (b) something that will
>>> turn into an incredible incomprehensible mess if we try
>>> to specify it on the command line. Why would we want to do that?
>>
>> It is an incomprehensible mess on the command line, but it is actually
>> quite fine if you use "-readconfig" instead.
> 
> Well, the justification for this whole new bus appears to be
> "so you can easily just add a new device on the command line".

"-readconfig" is another way to write command line options, e.g.

   [drive "hd"]
      file = /home/pbonzini/test.img
      if = none

   [device]
      driver = "virtio-blk"
      drive = hd

or something like that.

>>>> Perhaps the user can plug daughterboards that connect to the SoC and add
>>>> an extra serial port, visible as yet another MMIO device.
>>>
>>> Pluggable daughterboards should be implemented by actually
>>> defining the bus/socket that exists between the mainboard
>>> and the daughterboard, so you could say -device my-daughterboard
>>> and have it plug in to the mainboard.
>>
>> The bus might just be the processor's data bus + the interrupt
>> controller's pins, basically the same as sysbus.
> 
> Yes, we should have easy support for defining a pluggable
> bus as a collection of pins.

And a container memory region too---in the end, this is what Alex's
platform bus does.

>> In fact, the main thing I dislike about Alex's patch is adding a new bus
>> instead of making sysbus devices "just work" as pluggable devices.
> 
> Agreed, more or less. Actually I'd rather sysbus devices
> went away -- the requirement for interrupt and GPIO and
> memory regions to all be defined as single arrays (so you
> have to know what interrupt line 3 happens to be, and
> that memory region 1 is the registers, and so on) is
> pretty unfriendly. We should be able to define all these
> as named connections.

Yeah, that's the icing on the cake. :)

Paolo

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Anthony Liguori]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 23 July 2013 13:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 23/07/2013 14:22, Peter Maydell ha scritto:
>>> On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Yes, we should have easy support for defining a pluggable
> bus as a collection of pins.
>
>> In fact, the main thing I dislike about Alex's patch is adding a new bus
>> instead of making sysbus devices "just work" as pluggable devices.
>
> Agreed, more or less. Actually I'd rather sysbus devices
> went away -- the requirement for interrupt and GPIO and
> memory regions to all be defined as single arrays (so you
> have to know what interrupt line 3 happens to be, and
> that memory region 1 is the registers, and so on) is
> pretty unfriendly. We should be able to define all these
> as named connections.

The concrete next steps here are well known.

1) Make MemoryRegion's QOM objects and add them as children to the
   devices that own them.

2) Make qemu_irq a QOM object.

Then you could use -device to plumb up all of these things without
SysBus being involved.

But the above is a lot of work for a use-case that while interesting
academically so far hasn't proven to be all that important.

Regards,

Anthony Liguori

>
> -- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 23 July 2013 15:26, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On 23 July 2013 13:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 23/07/2013 14:22, Peter Maydell ha scritto:
>>>> On 23 July 2013 13:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Yes, we should have easy support for defining a pluggable
>> bus as a collection of pins.
>>
>>> In fact, the main thing I dislike about Alex's patch is adding a new bus
>>> instead of making sysbus devices "just work" as pluggable devices.
>>
>> Agreed, more or less. Actually I'd rather sysbus devices
>> went away -- the requirement for interrupt and GPIO and
>> memory regions to all be defined as single arrays (so you
>> have to know what interrupt line 3 happens to be, and
>> that memory region 1 is the registers, and so on) is
>> pretty unfriendly. We should be able to define all these
>> as named connections.
>
> The concrete next steps here are well known.
>
> 1) Make MemoryRegion's QOM objects and add them as children to the
>    devices that own them.
>
> 2) Make qemu_irq a QOM object.
>
> Then you could use -device to plumb up all of these things without
> SysBus being involved.
>
> But the above is a lot of work for a use-case that while interesting
> academically so far hasn't proven to be all that important.

Yeah, I've generally been happy to limp along with the current
sysbus stuff; I'm just saying that if we want to be able to
create arbitrary MMIO devices on the command line (which is what
this patchset seems to be trying to achieve) we should do it
in the way you suggest above.

-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[François Revol]

On 23/07/2013 14:19, Paolo Bonzini wrote:
> Il 22/07/2013 20:21, Peter Maydell ha scritto:
>>>> >> > Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>>>> >> > device creation world of QEMU. Devices on these were modeled as SysBus devices
>>>> >> > which can only be instantiated in machine files, not through -device.
>>>> >> >
>>>> >> > Why is that so?
>> > Because you can't as a user of this sort of hardware
>> > plug in an extra serial port to a SoC, because there's just nowhere
>> > to plug it in. So why should it be possible to plug an extra
>> > serial port into the QEMU model of the SoC?
> And why exactly should QEMU be limited to modeling an existing SoC?
> 
> Perhaps the user is not working with an existing SoC.  They are working
> with with IP building blocks that they can combine the way they prefer,
> and they haven't yet made up their mind on the exact set of devices
> they'll have.  (because not all the world is a PC, but then not all the
> non-PC world is ARM either).
> 
> Perhaps the user is working on kernel support for device tree / ACPI,
> wants to test many device combinations, and does not want to touch C
> code in order to do that.

For what it's worth, ont sure it matters here, but the Sam460ex (PPC)
(I've been writing code to support it recently) has an FDT, and a PCI
controller...
And there is a firmware setting to switch between the 2nd SATA port and
the PCI-e slot as they are mutually exclusive...

François.

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
> device creation world of QEMU. Devices on these were modeled as SysBus devices
> which can only be instantiated in machine files, not through -device.
>
> Why is that so?
>
> Well, SysBus is trying to be incredibly generic. It allows you to plug any
> interrupt sender into any other interrupt receiver. It allows you to map
> a device's memory regions into any other random memory region. All of that
> only works from C code.
>
> But do we need that level of complexity for normal devices usually? In a
> normal platform world (SoCs, PV machines) we have a flat memory layout we
> can plug our device memory into. We also have a flat IRQ model where we
> can plug our device IRQs into.
>
> This platform bus creates a simple bus that models the easy world. It allows
> for dynamic device creation through -device. A device may or may not explictly
> request to be mapped at a specific IRQ and/or memory address. If no explicit
> mapping is requested, platform devices just get mapped at convenient places.
>
> This goes hand in hand with automatic device tree generation. When QEMU
> places devices somewhere and also generates a device tree to tell the guest
> where exactly those devices are, we close the cycle and everyone knows
> everything and lives happily ever after.
>
> The actual pressing issue this solves is that today it's impossible to spawn
> serial ports from the command line. With this patch set, it's possible to
> do so. But it lays the groundwork for much more...

tl;dr, this is a PV bus for the e500 described as something more
generic.  I don't buy it.  I don't think there are many platforms or
devices out there where you can arbitrarily hook up devices at random
offsets/IRQs and expect things to work in any meaningful way.

So I'll suggest one of three things:

1) Just use PCI and call it a day

2) Rename this to E500PlatformBus and call it a day

3) If you really want to solve the general problem of platform devices,
   I think the approach needs to involve:

   a) Forget about any bus at all, just inherit from a common base class

   b) Use the common base class to expose interfaces to enumerate IRQs
      and MemoryRegions

   c) Have machine-specific logic (in the post init hook) that looks for
      any device of the type defined in (a) and connects their
      IRQs/MemoryRegions as appropriate.

   I can believe that this approach could be reasonably generic.  It's
   not abnormal for a hardware vendor to produce a single chip with all
   of the possible silicon on it and disable bits and pieces in order to
   offer a wider range of products.

   In this case, I could believe that a single SoC family could have up
   to four network adapters but I would also expect these adapters to
   live in four well known places.  With a machine specific hook, you
   can look at the specific device type and make these types of
   decisions appropriately.

Regards,

Anthony Liguori

>
> Alex
>
> Alexander Graf (9):
>   PlatBus: Add Platform Bus
>   PlatBus: Add abstract Platform Device
>   PlatBus: Add Sysbus/Platform bridge device
>   PlatBus: Hook up into Makefile system
>   PPC: Add platform bus to the default compile set
>   PlatBus: Add serial-platbus device
>   PPC: Add PlatBus Serial to default configs
>   PPC: E500: Spawn PlatBus bridge for ppce500 machine
>   PPC: E500: Add PlatBus device tree walker
>
>  default-configs/ppc-softmmu.mak    |   2 +
>  default-configs/ppc64-softmmu.mak  |   2 +
>  default-configs/ppcemb-softmmu.mak |   2 +
>  hw/Makefile.objs                   |   1 +
>  hw/char/Makefile.objs              |   1 +
>  hw/char/serial-platbus.c           | 100 +++++++++++++++++++++++
>  hw/platbus/Makefile.objs           |   1 +
>  hw/platbus/bridge.c                |  64 +++++++++++++++
>  hw/platbus/device.c                | 162 +++++++++++++++++++++++++++++++++++++
>  hw/platbus/platbus.c               | 107 ++++++++++++++++++++++++
>  hw/ppc/e500.c                      |  75 ++++++++++++++++-
>  hw/ppc/e500.h                      |   1 +
>  hw/ppc/e500plat.c                  |   1 +
>  include/hw/char/serial-platbus.h   |  56 +++++++++++++
>  include/hw/platbus/bridge.h        |  32 ++++++++
>  include/hw/platbus/device.h        | 102 +++++++++++++++++++++++
>  include/hw/platbus/platbus.h       |  86 ++++++++++++++++++++
>  17 files changed, 791 insertions(+), 4 deletions(-)
>  create mode 100644 hw/char/serial-platbus.c
>  create mode 100644 hw/platbus/Makefile.objs
>  create mode 100644 hw/platbus/bridge.c
>  create mode 100644 hw/platbus/device.c
>  create mode 100644 hw/platbus/platbus.c
>  create mode 100644 include/hw/char/serial-platbus.h
>  create mode 100644 include/hw/platbus/bridge.h
>  create mode 100644 include/hw/platbus/device.h
>  create mode 100644 include/hw/platbus/platbus.h
>
> -- 
> 1.8.1.4

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Alexander Graf]

On 22.07.2013, at 21:38, Anthony Liguori wrote:

> Alexander Graf <agraf@suse.de> writes:
> 
>> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>> device creation world of QEMU. Devices on these were modeled as SysBus devices
>> which can only be instantiated in machine files, not through -device.
>> 
>> Why is that so?
>> 
>> Well, SysBus is trying to be incredibly generic. It allows you to plug any
>> interrupt sender into any other interrupt receiver. It allows you to map
>> a device's memory regions into any other random memory region. All of that
>> only works from C code.
>> 
>> But do we need that level of complexity for normal devices usually? In a
>> normal platform world (SoCs, PV machines) we have a flat memory layout we
>> can plug our device memory into. We also have a flat IRQ model where we
>> can plug our device IRQs into.
>> 
>> This platform bus creates a simple bus that models the easy world. It allows
>> for dynamic device creation through -device. A device may or may not explictly
>> request to be mapped at a specific IRQ and/or memory address. If no explicit
>> mapping is requested, platform devices just get mapped at convenient places.
>> 
>> This goes hand in hand with automatic device tree generation. When QEMU
>> places devices somewhere and also generates a device tree to tell the guest
>> where exactly those devices are, we close the cycle and everyone knows
>> everything and lives happily ever after.
>> 
>> The actual pressing issue this solves is that today it's impossible to spawn
>> serial ports from the command line. With this patch set, it's possible to
>> do so. But it lays the groundwork for much more...
> 
> tl;dr, this is a PV bus for the e500 described as something more
> generic.  I don't buy it.  I don't think there are many platforms or
> devices out there where you can arbitrarily hook up devices at random
> offsets/IRQs and expect things to work in any meaningful way.
> 
> So I'll suggest one of three things:
> 
> 1) Just use PCI and call it a day

If only the world was this easy. We already use PCI for everything where it makes sense today, but some devices I want to create dynamically from the command line simply aren't on PCI.

> 2) Rename this to E500PlatformBus and call it a day

This could be used just the same for ARM's mach-virt, so I'd rather not make it e500 specific.

> 3) If you really want to solve the general problem of platform devices,
>   I think the approach needs to involve:
> 
>   a) Forget about any bus at all, just inherit from a common base class
> 
>   b) Use the common base class to expose interfaces to enumerate IRQs
>      and MemoryRegions
> 
>   c) Have machine-specific logic (in the post init hook) that looks for
>      any device of the type defined in (a) and connects their
>      IRQs/MemoryRegions as appropriate.

Ok, I have something very similar for the device tree walker anyways, just that I'm walking a bus instead of the global device pool. But the idea is probably still the same. I suppose I'd still inherit from PlatBusDevice (which obviously would be called PlatformDevice or SimpleDevice by then) to get me my interfaces, right?

I'll see what I can come up with.


Alex

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> On 22.07.2013, at 21:38, Anthony Liguori wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>> 
>> tl;dr, this is a PV bus for the e500 described as something more
>> generic.  I don't buy it.  I don't think there are many platforms or
>> devices out there where you can arbitrarily hook up devices at random
>> offsets/IRQs and expect things to work in any meaningful way.
>> 
>> So I'll suggest one of three things:
>> 
>> 1) Just use PCI and call it a day
>
> If only the world was this easy. We already use PCI for everything where it makes sense today, but some devices I want to create dynamically from the command line simply aren't on PCI.
>
>> 2) Rename this to E500PlatformBus and call it a day
>
> This could be used just the same for ARM's mach-virt, so I'd rather
> not make it e500 specific.

If someone designed a "virt" machine and didn't include PCI or some
other sane existing bus...

It's just silly to reinvent things that already exist and are well
supported by existing software/management tools.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 22 July 2013 20:52, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Alexander Graf <agraf@suse.de> writes:
>> On 22.07.2013, at 21:38, Anthony Liguori wrote:
>>
>> This could be used just the same for ARM's mach-virt, so I'd rather
>> not make it e500 specific.
>
> If someone designed a "virt" machine and didn't include PCI or some
> other sane existing bus...

"mach-virt" just means "completely described by device tree
with no knowledge hardcoded in the kernel about the platform".
We don't currently have any PCI host controller which is:
(a) for ARM
(b) entirely device tree driven
(c) supported by QEMU
(d) with a decent Linux driver

So mach-virt doesn't have PCI; it will use virtio-mmio,
same as kvmtool for ARM does.

-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Anthony Liguori]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 22 July 2013 20:52, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Alexander Graf <agraf@suse.de> writes:
>>> On 22.07.2013, at 21:38, Anthony Liguori wrote:
>>>
>>> This could be used just the same for ARM's mach-virt, so I'd rather
>>> not make it e500 specific.
>>
>> If someone designed a "virt" machine and didn't include PCI or some
>> other sane existing bus...
>
> "mach-virt" just means "completely described by device tree
> with no knowledge hardcoded in the kernel about the platform".

Fair enough.

> We don't currently have any PCI host controller which is:
> (a) for ARM

In QEMU?  You can make one super easily by just extending PCIHostState.

It's just a matter of mapping the index and data registers somewhere.

I can't believe it's that hard to get this working in Linux either.

> (b) entirely device tree driven

I'm not sure what this means, but presumably it wouldn't be hard to do
the above.

> (c) supported by QEMU

This part is easy enough.

> (d) with a decent Linux driver

See above.

>
> So mach-virt doesn't have PCI; it will use virtio-mmio,
> same as kvmtool for ARM does.

That's all well and fine but there are a lot of advantages to having PCI
and being able to use all of the features associated with it.

It's always tempting to reinvent the wheel when given the chance but I
think in the long term, you'll regret it.

Regards,

Anthony Liguori

>
> -- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Peter Maydell]

On 22 July 2013 23:05, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> We don't currently have any PCI host controller which is:
>> (a) for ARM
>
> In QEMU?  You can make one super easily by just extending PCIHostState.
>
> It's just a matter of mapping the index and data registers somewhere.

That's a model of some random nonexistent thing, not a model
of a piece of hardware or silicon that actually exists and
thus that there's some hope the kernel might someday maybe
be able to drive properly.

> I can't believe it's that hard to get this working in Linux either.

Actual ARM hardware with PCI is rare; the overlap of
that with "ARM hardware we model in QEMU" is pretty near
zero. And we demonstrably can't get the kernel folks to write
working driver code for a PCI controller that only exists in
QEMU -- just look at the trainwreck which is the versatile PCI
kernel code.

>> (b) entirely device tree driven
>
> I'm not sure what this means, but presumably it wouldn't be
> hard to do the above.

It means "not tied up with assumptions that the PCI
controller is sitting in whatever SoC it sits in in hardware,
with the clock and power control and etc etc etc that that
PCI controller has in hardware". In other words, such that
you can just drop a model of that controller into a random
nonexistent board and have it work, rather than having to
model an entire complex SoC because the driver code (entirely
reasonably) assumes the hardware is always in that SoC.

>> (c) supported by QEMU
>
> This part is easy enough.

Modelling a PCI controller isn't so hard. Modelling the
SoC it sits in is much harder.

>> (d) with a decent Linux driver
>
> See above.

See my remarks above too :-)

>> So mach-virt doesn't have PCI; it will use virtio-mmio,
>> same as kvmtool for ARM does.
>
> That's all well and fine but there are a lot of advantages to having PCI
> and being able to use all of the features associated with it.

I completely agree. The reason we're here with virtio-mmio
is because of the gaping lack of PCI for ARM yet. This will
improve, I'm sure, but just now there simply isn't a
sensible device we can model that I'm aware of. I'm open
to suggestions if anybody has them.

-- PMM

Re: [Qemu-devel] [PATCH 0/9] Add platform bus

[Andreas Färber]

Am 23.07.2013 00:34, schrieb Peter Maydell:
> On 22 July 2013 23:05, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> We don't currently have any PCI host controller which is:
>>> (a) for ARM
>>
>> In QEMU?  You can make one super easily by just extending PCIHostState.
>>
>> It's just a matter of mapping the index and data registers somewhere.
> 
> That's a model of some random nonexistent thing, not a model
> of a piece of hardware or silicon that actually exists and
> thus that there's some hope the kernel might someday maybe
> be able to drive properly.
> 
>> I can't believe it's that hard to get this working in Linux either.
> 
> Actual ARM hardware with PCI is rare; the overlap of
> that with "ARM hardware we model in QEMU" is pretty near
> zero. And we demonstrably can't get the kernel folks to write
> working driver code for a PCI controller that only exists in
> QEMU -- just look at the trainwreck which is the versatile PCI
> kernel code.

FWIW the Nvidia Tegra3 SoC has PCIe, e.g., the Toradex Apalis T30 SoM.
With the Ixora board that's coming into affordable territory for devs.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg