[Qemu-devel] [PATCH v5 0/6] spapr: bootindex support

[Qemu-devel] [PATCH v5 0/6] spapr: bootindex support

[Alexey Kardashevskiy]

This time I grouped patches into 2 groups - the first 3 patches
are platform independent and last 3 are for sPAPR machine. Not many updates,
just some code style fixes and rebased on top of qemu.org/master + agraf/ppc-next.

Please comment. Thanks.


Alexey Kardashevskiy (5):
  boot: extend get_boot_devices_list() to ignore suffixes
  qdev: introduce FWPathProvider interface
  spapr-llan: add to boot device list
  spapr-vio: fix firmware names
  spapr: define interface to fix device pathname

Paolo Bonzini (1):
  vl: allow customizing the class of /machine

 hw/core/Makefile.objs         |   1 +
 hw/core/fw-path-provider.c    |  51 +++++++++++++++++++++
 hw/core/qdev.c                |  18 +++++++-
 hw/net/spapr_llan.c           |   3 ++
 hw/nvram/fw_cfg.c             |   2 +-
 hw/ppc/spapr.c                | 103 +++++++++++++++++++++++++++++++++++++++++-
 hw/ppc/spapr_vio.c            |   3 ++
 include/hw/boards.h           |   1 +
 include/hw/fw-path-provider.h |  49 ++++++++++++++++++++
 include/sysemu/sysemu.h       |   2 +-
 tests/Makefile                |   1 +
 vl.c                          |  13 ++++--
 12 files changed, 240 insertions(+), 7 deletions(-)
 create mode 100644 hw/core/fw-path-provider.c
 create mode 100644 include/hw/fw-path-provider.h

-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Alexey Kardashevskiy]

As suffixes do not make sense for sPAPR's device tree and
there is no way to filter them out on the BusState::get_fw_dev_path
level, let's add an ability for the external caller to specify
whether to apply suffixes or not.

We could handle suffixes in SLOF (ignore for now) but this would require
serious rework in the node opening code in SLOF which has no obvious
benefit for the currently emulated sPAPR machine.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v4:
* changed commit message about not having plans in SLOF rework as it is scary :)
---
 hw/nvram/fw_cfg.c       | 2 +-
 include/sysemu/sysemu.h | 2 +-
 vl.c                    | 8 +++++---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index ee96c16..42fa448 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -504,7 +504,7 @@ static void fw_cfg_machine_ready(struct Notifier *n, void *data)
 {
     size_t len;
     FWCfgState *s = container_of(n, FWCfgState, machine_ready);
-    char *bootindex = get_boot_devices_list(&len);
+    char *bootindex = get_boot_devices_list(&len, false);
 
     fw_cfg_add_file(s, "bootorder", (uint8_t*)bootindex, len);
 }
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 495dae8..2b71a4a 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -185,7 +185,7 @@ void rtc_change_mon_event(struct tm *tm);
 
 void add_boot_device_path(int32_t bootindex, DeviceState *dev,
                           const char *suffix);
-char *get_boot_devices_list(size_t *size);
+char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
 
 DeviceState *get_boot_device(uint32_t position);
 
diff --git a/vl.c b/vl.c
index 57e98fa..01ab7e4 100644
--- a/vl.c
+++ b/vl.c
@@ -1166,7 +1166,7 @@ DeviceState *get_boot_device(uint32_t position)
  * memory pointed by "size" is assigned total length of the array in bytes
  *
  */
-char *get_boot_devices_list(size_t *size)
+char *get_boot_devices_list(size_t *size, bool ignore_suffixes)
 {
     FWBootEntry *i;
     size_t total = 0;
@@ -1181,7 +1181,7 @@ char *get_boot_devices_list(size_t *size)
             assert(devpath);
         }
 
-        if (i->suffix && devpath) {
+        if (i->suffix && !ignore_suffixes && devpath) {
             size_t bootpathlen = strlen(devpath) + strlen(i->suffix) + 1;
 
             bootpath = g_malloc(bootpathlen);
@@ -1189,9 +1189,11 @@ char *get_boot_devices_list(size_t *size)
             g_free(devpath);
         } else if (devpath) {
             bootpath = devpath;
-        } else {
+        } else if (!ignore_suffixes) {
             assert(i->suffix);
             bootpath = g_strdup(i->suffix);
+        } else {
+            bootpath = g_strdup("");
         }
 
         if (total) {
-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Alexey Kardashevskiy]

QEMU supports firmware names for all devices in the QEMU tree but
some architectures expect some parts of firmware path names in different
format.

This introduces a firmware-pathname-change interface definition.
If some machines needs to redefine the firmware path format, it has
to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
the device on the QOM tree (typically /machine).

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
Changes:
v5:
* fixed code design
* added license headers

v4:
* added fw-path-provider.o into tests/Makefile
* fixed 80chars warning from checkpatch.pl
---
 hw/core/Makefile.objs         |  1 +
 hw/core/fw-path-provider.c    | 51 +++++++++++++++++++++++++++++++++++++++++++
 hw/core/qdev.c                | 18 ++++++++++++++-
 include/hw/fw-path-provider.h | 49 +++++++++++++++++++++++++++++++++++++++++
 tests/Makefile                |  1 +
 5 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 hw/core/fw-path-provider.c
 create mode 100644 include/hw/fw-path-provider.h

diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index 9e324be..9f75ea3 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -1,5 +1,6 @@
 # core qdev-related obj files, also used by *-user:
 common-obj-y += qdev.o qdev-properties.o
+common-obj-y += fw-path-provider.o
 # irq.o needed for qdev GPIO handling:
 common-obj-y += irq.o
 common-obj-y += hotplug.o
diff --git a/hw/core/fw-path-provider.c b/hw/core/fw-path-provider.c
new file mode 100644
index 0000000..b117157
--- /dev/null
+++ b/hw/core/fw-path-provider.c
@@ -0,0 +1,51 @@
+/*
+ *  Firmware patch provider class and helpers.
+ *
+ *  This program 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; under version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw/fw-path-provider.h"
+
+char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
+                                    DeviceState *dev)
+{
+    FWPathProviderClass *k = FW_PATH_PROVIDER_GET_CLASS(p);
+
+    return k->get_dev_path(p, bus, dev);
+}
+
+char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
+                                        DeviceState *dev)
+{
+    FWPathProvider *p = (FWPathProvider *)
+        object_dynamic_cast(o, TYPE_FW_PATH_PROVIDER);
+
+    if (p) {
+        return fw_path_provider_get_dev_path(p, bus, dev);
+    }
+
+    return NULL;
+}
+
+static const TypeInfo fw_path_provider_info = {
+    .name          = TYPE_FW_PATH_PROVIDER,
+    .parent        = TYPE_INTERFACE,
+    .class_size    = sizeof(FWPathProviderClass),
+};
+
+static void fw_path_provider_register_types(void)
+{
+    type_register_static(&fw_path_provider_info);
+}
+
+type_init(fw_path_provider_register_types)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index ae30163..dd993b5 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -26,6 +26,7 @@
    this API directly.  */
 
 #include "hw/qdev.h"
+#include "hw/fw-path-provider.h"
 #include "sysemu/sysemu.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qerror.h"
@@ -529,6 +530,18 @@ static char *bus_get_fw_dev_path(BusState *bus, DeviceState *dev)
     return NULL;
 }
 
+static char *qdev_get_fw_dev_path_from_handler(BusState *bus, DeviceState *dev)
+{
+    Object *obj = OBJECT(dev);
+    char *d = NULL;
+
+    while (!d && obj->parent) {
+        obj = obj->parent;
+        d = fw_path_provider_try_get_dev_path(obj, bus, dev);
+    }
+    return d;
+}
+
 static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
 {
     int l = 0;
@@ -536,7 +549,10 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
     if (dev && dev->parent_bus) {
         char *d;
         l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
-        d = bus_get_fw_dev_path(dev->parent_bus, dev);
+        d = qdev_get_fw_dev_path_from_handler(dev->parent_bus, dev);
+        if (!d) {
+            d = bus_get_fw_dev_path(dev->parent_bus, dev);
+        }
         if (d) {
             l += snprintf(p + l, size - l, "%s", d);
             g_free(d);
diff --git a/include/hw/fw-path-provider.h b/include/hw/fw-path-provider.h
new file mode 100644
index 0000000..8889d8b
--- /dev/null
+++ b/include/hw/fw-path-provider.h
@@ -0,0 +1,49 @@
+/*
+ *  Firmware patch provider class and helpers definitions.
+ *
+ *  This program 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; under version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef FW_PATH_PROVIDER_H
+#define FW_PATH_PROVIDER_H 1
+
+#include "qemu-common.h"
+#include "qom/object.h"
+
+#define TYPE_FW_PATH_PROVIDER "fw-path-provider"
+
+#define FW_PATH_PROVIDER_CLASS(klass) \
+     OBJECT_CLASS_CHECK(FWPathProviderClass, (klass), TYPE_FW_PATH_PROVIDER)
+#define FW_PATH_PROVIDER_GET_CLASS(obj) \
+    OBJECT_GET_CLASS(FWPathProviderClass, (obj), TYPE_FW_PATH_PROVIDER)
+#define FW_PATH_PROVIDER(obj) \
+     INTERFACE_CHECK(FWPathProvider, (obj), TYPE_FW_PATH_PROVIDER)
+
+typedef struct FWPathProvider {
+    Object parent_obj;
+} FWPathProvider;
+
+typedef void (*StreamCanPushNotifyFn)(void *opaque);
+
+typedef struct FWPathProviderClass {
+    InterfaceClass parent_class;
+
+    char *(*get_dev_path)(FWPathProvider *p, BusState *bus, DeviceState *dev);
+} FWPathProviderClass;
+
+char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
+                                    DeviceState *dev);
+char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
+                                        DeviceState *dev);
+
+#endif /* FW_PATH_PROVIDER_H */
diff --git a/tests/Makefile b/tests/Makefile
index 9a7d2f1..0692b11 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -165,6 +165,7 @@ tests/test-int128$(EXESUF): tests/test-int128.o
 tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \
 	hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\
 	hw/core/irq.o \
+	hw/core/fw-path-provider.o \
 	$(qom-core-obj) \
 	$(test-qapi-obj-y) \
 	libqemuutil.a libqemustub.a
-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

From: Paolo Bonzini <pbonzini@redhat.com>

This is a first step towards QOMifying /machine.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 include/hw/boards.h | 1 +
 vl.c                | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index c2096e6..8640272 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -29,6 +29,7 @@ struct QEMUMachine {
     const char *name;
     const char *alias;
     const char *desc;
+    const char *class_name;
     QEMUMachineInitFunc *init;
     QEMUMachineResetFunc *reset;
     QEMUMachineHotAddCPUFunc *hot_add_cpu;
diff --git a/vl.c b/vl.c
index 01ab7e4..b300721 100644
--- a/vl.c
+++ b/vl.c
@@ -4034,6 +4034,11 @@ int main(int argc, char **argv, char **envp)
         qtest_init(qtest_chrdev, qtest_log);
     }
 
+    if (machine->class_name) {
+        Object *m = object_new(machine->class_name);
+        object_property_add_child(object_get_root(), "machine", m, NULL);
+    }
+
     machine_opts = qemu_get_machine_opts();
     kernel_filename = qemu_opt_get(machine_opts, "kernel");
     initrd_filename = qemu_opt_get(machine_opts, "initrd");
-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 4/6] spapr-llan: add to boot device list

[Alexey Kardashevskiy]

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 hw/net/spapr_llan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 1bd6f50..229de00 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -29,6 +29,7 @@
 #include "hw/qdev.h"
 #include "hw/ppc/spapr.h"
 #include "hw/ppc/spapr_vio.h"
+#include "sysemu/sysemu.h"
 
 #include <libfdt.h>
 
@@ -213,6 +214,8 @@ static int spapr_vlan_init(VIOsPAPRDevice *sdev)
                             object_get_typename(OBJECT(sdev)), sdev->qdev.id, dev);
     qemu_format_nic_info_str(qemu_get_queue(dev->nic), dev->nicconf.macaddr.a);
 
+    add_boot_device_path(dev->nicconf.bootindex, DEVICE(dev), "");
+
     return 0;
 }
 
-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 5/6] spapr-vio: fix firmware names

[Alexey Kardashevskiy]

This changes VIO bridge fw name from spapr-vio-bridge to vdevice and
vscsi/veth node names from QEMU object names to VIO specific device tree
names.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 hw/ppc/spapr_vio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
index 4e33f46..2ae06a3 100644
--- a/hw/ppc/spapr_vio.c
+++ b/hw/ppc/spapr_vio.c
@@ -68,6 +68,7 @@ static void spapr_vio_bus_class_init(ObjectClass *klass, void *data)
     BusClass *k = BUS_CLASS(klass);
 
     k->get_dev_path = spapr_vio_get_dev_name;
+    k->get_fw_dev_path = spapr_vio_get_dev_name;
 }
 
 static const TypeInfo spapr_vio_bus_info = {
@@ -529,7 +530,9 @@ static int spapr_vio_bridge_init(SysBusDevice *dev)
 static void spapr_vio_bridge_class_init(ObjectClass *klass, void *data)
 {
     SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
+    DeviceClass *dc = DEVICE_CLASS(klass);
 
+    dc->fw_name = "vdevice";
     k->init = spapr_vio_bridge_init;
 }
 
-- 
1.8.4.rc4

[Qemu-devel] [PATCH v5 6/6] spapr: define interface to fix device pathname

[Alexey Kardashevskiy]

This defines an object with the interface to fix firmware pathnames
for devices which have @bootindex property.

This fixes SCSI disks device node names (which are wildcard nodes in
the device-tree), for spapr-vsci, virtio-scsi and usb-storage.

This fixes PHB name from "pci" to "pci@XXXX" where XXXX is a BUID as
there is no bus on top of sPAPRPHBState where PHB firmware name could
be fixed using the BusClass::get_fw_dev_path mechanism.

This stores the boot list in the /chosen/qemu,boot-list property of
the device tree. "\n" are replaced by spaces to support OF1275.
SLOF needs an update in order to support the boot list.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v5:
* addev virtio and usb handling

v2:
* added special handling for virtio-scsi and USB as they use different
LUN encoding in SLOF
---
 hw/ppc/spapr.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 102 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 0989ed6..79f6a5d 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -26,6 +26,7 @@
  */
 #include "sysemu/sysemu.h"
 #include "hw/hw.h"
+#include "hw/fw-path-provider.h"
 #include "elf.h"
 #include "net/net.h"
 #include "sysemu/blockdev.h"
@@ -45,6 +46,8 @@
 #include "hw/pci/msi.h"
 
 #include "hw/pci/pci.h"
+#include "hw/scsi/scsi.h"
+#include "hw/virtio/virtio-scsi.h"
 
 #include "exec/address-spaces.h"
 #include "hw/usb.h"
@@ -81,6 +84,8 @@
 
 #define HTAB_SIZE(spapr)        (1ULL << ((spapr)->htab_shift))
 
+#define TYPE_SPAPR_MACHINE      "machine-spapr"
+
 sPAPREnvironment *spapr;
 
 int spapr_allocate_irq(int hint, bool lsi)
@@ -597,7 +602,9 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
                                hwaddr rtas_addr,
                                hwaddr rtas_size)
 {
-    int ret;
+    int ret, i;
+    size_t cb = 0;
+    char *bootlist;
     void *fdt;
     sPAPRPHBState *phb;
 
@@ -639,6 +646,21 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
         fprintf(stderr, "Couldn't finalize CPU device tree properties\n");
     }
 
+    bootlist = get_boot_devices_list(&cb, true);
+    if (cb && bootlist) {
+        int offset = fdt_path_offset(fdt, "/chosen");
+        if (offset < 0) {
+            exit(1);
+        }
+        for (i = 0; i < cb; i++) {
+            if (bootlist[i] == '\n') {
+                bootlist[i] = ' ';
+            }
+
+        }
+        ret = fdt_setprop_string(fdt, offset, "qemu,boot-list", bootlist);
+    }
+
     if (!spapr->has_graphics) {
         spapr_populate_chosen_stdout(fdt, spapr->vio_bus);
     }
@@ -1390,6 +1412,7 @@ static int spapr_kvm_type(const char *vm_type)
 static QEMUMachine spapr_machine = {
     .name = "pseries",
     .desc = "pSeries Logical Partition (PAPR compliant)",
+    .class_name = TYPE_SPAPR_MACHINE,
     .is_default = 1,
     .init = ppc_spapr_init,
     .reset = ppc_spapr_reset,
@@ -1406,3 +1429,81 @@ static void spapr_machine_init(void)
 }
 
 machine_init(spapr_machine_init);
+
+/*
+ * Implementation of an interface to adjust firmware patch
+ * for the bootindex property handling.
+ */
+static char *spapr_get_fw_dev_path(FWPathProvider *p, BusState *bus,
+                                   DeviceState *dev)
+{
+#define CAST(type, obj, name) \
+    ((type *)object_dynamic_cast(OBJECT(obj), (name)))
+    SCSIDevice *d = CAST(SCSIDevice,  dev, TYPE_SCSI_DEVICE);
+    sPAPRPHBState *phb = CAST(sPAPRPHBState, dev, TYPE_SPAPR_PCI_HOST_BRIDGE);
+
+    if (d) {
+        void *spapr = CAST(void, bus->parent, "spapr-vscsi");
+        VirtIOSCSI *virtio = CAST(VirtIOSCSI, bus->parent, TYPE_VIRTIO_SCSI);
+        USBDevice *usb = CAST(USBDevice, bus->parent, TYPE_USB_DEVICE);
+
+        if (spapr) {
+            /*
+             * Replace "channel@0/disk@0,0" with "disk@8000000000000000":
+             * We use SRP luns of the form 8000 | (bus << 8) | (id << 5) | lun
+             * in the top 16 bits of the 64-bit LUN
+             */
+            unsigned id = 0x8000 | (d->id << 8) | d->lun;
+            return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
+                                   (uint64_t)id << 48);
+        } else if (virtio) {
+            /*
+             * We use SRP luns of the form 01000000 | (target << 8) | lun
+             * in the top 32 bits of the 64-bit LUN
+             */
+            unsigned id = 0x1000000 | (d->id << 8) | d->lun;
+            return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
+                                   (uint64_t)id << 32);
+        } else if (usb) {
+            /*
+             * We use SRP luns of the form 01000000 | (usb-port << 16) | lun
+             * in the top 32 bits of the 64-bit LUN
+             */
+            unsigned usb_port = atoi(usb->port->path);
+            unsigned id = 0x1000000 | (usb_port << 16) | d->lun;
+            return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
+                                   (uint64_t)id << 32);
+        }
+    }
+
+    if (phb) {
+        /* Replace "pci" with "pci@800000020000000" */
+        return g_strdup_printf("pci@%"PRIX64, phb->buid);
+    }
+
+    return NULL;
+}
+
+static void spapr_machine_class_init(ObjectClass *oc, void *data)
+{
+    FWPathProviderClass *fwc = FW_PATH_PROVIDER_CLASS(oc);
+
+    fwc->get_dev_path = spapr_get_fw_dev_path;
+}
+
+static const TypeInfo spapr_machine_info = {
+    .name          = TYPE_SPAPR_MACHINE,
+    .parent        = TYPE_OBJECT,
+    .class_init    = spapr_machine_class_init,
+    .interfaces = (InterfaceInfo[]) {
+            { TYPE_FW_PATH_PROVIDER },
+            { }
+    }
+};
+
+static void spapr_machine_register_types(void)
+{
+    type_register_static(&spapr_machine_info);
+}
+
+type_init(spapr_machine_register_types)
-- 
1.8.4.rc4

Re: [Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Paolo Bonzini]

Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
> As suffixes do not make sense for sPAPR's device tree and
> there is no way to filter them out on the BusState::get_fw_dev_path
> level, let's add an ability for the external caller to specify
> whether to apply suffixes or not.
>
> We could handle suffixes in SLOF (ignore for now) but this would require
> serious rework in the node opening code in SLOF which has no obvious
> benefit for the currently emulated sPAPR machine.

For the record, the commit message is not entirely correct in presenting 
the situation.  QEMU *does not care in any way* of benefits for the 
currently emulated sPAPR machine.  The benefit would be to QEMU in 
having simpler code.

You just got a wildcard because Forth is scary. :)

Paolo

> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v4:
> * changed commit message about not having plans in SLOF rework as it is scary :)

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> This is a first step towards QOMifying /machine.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

The patch was originally mine, so I could get it in if Andreas wants me 
to handle patches 2-3.  But for anyone else it would be missing your 
S-o-b line.

Paolo

> ---
>  include/hw/boards.h | 1 +
>  vl.c                | 5 +++++
>  2 files changed, 6 insertions(+)
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index c2096e6..8640272 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -29,6 +29,7 @@ struct QEMUMachine {
>      const char *name;
>      const char *alias;
>      const char *desc;
> +    const char *class_name;
>      QEMUMachineInitFunc *init;
>      QEMUMachineResetFunc *reset;
>      QEMUMachineHotAddCPUFunc *hot_add_cpu;
> diff --git a/vl.c b/vl.c
> index 01ab7e4..b300721 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4034,6 +4034,11 @@ int main(int argc, char **argv, char **envp)
>          qtest_init(qtest_chrdev, qtest_log);
>      }
>
> +    if (machine->class_name) {
> +        Object *m = object_new(machine->class_name);
> +        object_property_add_child(object_get_root(), "machine", m, NULL);
> +    }
> +
>      machine_opts = qemu_get_machine_opts();
>      kernel_filename = qemu_opt_get(machine_opts, "kernel");
>      initrd_filename = qemu_opt_get(machine_opts, "initrd");
>

Re: [Qemu-devel] [PATCH v5 0/6] spapr: bootindex support

[Paolo Bonzini]

Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
> This time I grouped patches into 2 groups - the first 3 patches
> are platform independent and last 3 are for sPAPR machine. Not many updates,
> just some code style fixes and rebased on top of qemu.org/master + agraf/ppc-next.
>
> Please comment. Thanks.

Good, but S-o-b in patch 3 is missing.

Paolo

>
> Alexey Kardashevskiy (5):
>   boot: extend get_boot_devices_list() to ignore suffixes
>   qdev: introduce FWPathProvider interface
>   spapr-llan: add to boot device list
>   spapr-vio: fix firmware names
>   spapr: define interface to fix device pathname
>
> Paolo Bonzini (1):
>   vl: allow customizing the class of /machine
>
>  hw/core/Makefile.objs         |   1 +
>  hw/core/fw-path-provider.c    |  51 +++++++++++++++++++++
>  hw/core/qdev.c                |  18 +++++++-
>  hw/net/spapr_llan.c           |   3 ++
>  hw/nvram/fw_cfg.c             |   2 +-
>  hw/ppc/spapr.c                | 103 +++++++++++++++++++++++++++++++++++++++++-
>  hw/ppc/spapr_vio.c            |   3 ++
>  include/hw/boards.h           |   1 +
>  include/hw/fw-path-provider.h |  49 ++++++++++++++++++++
>  include/sysemu/sysemu.h       |   2 +-
>  tests/Makefile                |   1 +
>  vl.c                          |  13 ++++--
>  12 files changed, 240 insertions(+), 7 deletions(-)
>  create mode 100644 hw/core/fw-path-provider.c
>  create mode 100644 include/hw/fw-path-provider.h
>

Re: [Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Alexey Kardashevskiy]

On 02/21/2014 12:55 AM, Paolo Bonzini wrote:
> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>> As suffixes do not make sense for sPAPR's device tree and
>> there is no way to filter them out on the BusState::get_fw_dev_path
>> level, let's add an ability for the external caller to specify
>> whether to apply suffixes or not.
>>
>> We could handle suffixes in SLOF (ignore for now) but this would require
>> serious rework in the node opening code in SLOF which has no obvious
>> benefit for the currently emulated sPAPR machine.
> 
> For the record, the commit message is not entirely correct in presenting
> the situation.  QEMU *does not care in any way* of benefits for the
> currently emulated sPAPR machine.  The benefit would be to QEMU in having
> simpler code.
> 
> You just got a wildcard because Forth is scary. :)

I know :) Should I remove that part and replace it with the "scary" one?


> Paolo
> 
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v4:
>> * changed commit message about not having plans in SLOF rework as it is
>> scary :)
> 
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 0/6] spapr: bootindex support

[Alexey Kardashevskiy]

On 02/21/2014 12:58 AM, Paolo Bonzini wrote:
> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>> This time I grouped patches into 2 groups - the first 3 patches
>> are platform independent and last 3 are for sPAPR machine. Not many updates,
>> just some code style fixes and rebased on top of qemu.org/master +
>> agraf/ppc-next.
>>
>> Please comment. Thanks.
> 
> Good, but S-o-b in patch 3 is missing.


Why does it matter? It is your patch, it will go through someone else's
tree and I just reposted it - I could have added "Reviewed-by" or
"Tested-by" or "Acked-by", but SOB...



> 
> Paolo
> 
>>
>> Alexey Kardashevskiy (5):
>>   boot: extend get_boot_devices_list() to ignore suffixes
>>   qdev: introduce FWPathProvider interface
>>   spapr-llan: add to boot device list
>>   spapr-vio: fix firmware names
>>   spapr: define interface to fix device pathname
>>
>> Paolo Bonzini (1):
>>   vl: allow customizing the class of /machine
>>
>>  hw/core/Makefile.objs         |   1 +
>>  hw/core/fw-path-provider.c    |  51 +++++++++++++++++++++
>>  hw/core/qdev.c                |  18 +++++++-
>>  hw/net/spapr_llan.c           |   3 ++
>>  hw/nvram/fw_cfg.c             |   2 +-
>>  hw/ppc/spapr.c                | 103
>> +++++++++++++++++++++++++++++++++++++++++-
>>  hw/ppc/spapr_vio.c            |   3 ++
>>  include/hw/boards.h           |   1 +
>>  include/hw/fw-path-provider.h |  49 ++++++++++++++++++++
>>  include/sysemu/sysemu.h       |   2 +-
>>  tests/Makefile                |   1 +
>>  vl.c                          |  13 ++++--
>>  12 files changed, 240 insertions(+), 7 deletions(-)
>>  create mode 100644 hw/core/fw-path-provider.c
>>  create mode 100644 include/hw/fw-path-provider.h
>>
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Paolo Bonzini]

Il 20/02/2014 15:03, Alexey Kardashevskiy ha scritto:
> On 02/21/2014 12:55 AM, Paolo Bonzini wrote:
>> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>>> As suffixes do not make sense for sPAPR's device tree and
>>> there is no way to filter them out on the BusState::get_fw_dev_path
>>> level, let's add an ability for the external caller to specify
>>> whether to apply suffixes or not.
>>>
>>> We could handle suffixes in SLOF (ignore for now) but this would require
>>> serious rework in the node opening code in SLOF which has no obvious
>>> benefit for the currently emulated sPAPR machine.
>>
>> For the record, the commit message is not entirely correct in presenting
>> the situation.  QEMU *does not care in any way* of benefits for the
>> currently emulated sPAPR machine.  The benefit would be to QEMU in having
>> simpler code.
>>
>> You just got a wildcard because Forth is scary. :)
>
> I know :) Should I remove that part and replace it with the "scary" one?

No, unless you have to respin for other reasons (I hope not).

Paolo

Re: [Qemu-devel] [PATCH v5 0/6] spapr: bootindex support

[Paolo Bonzini]

Il 20/02/2014 15:05, Alexey Kardashevskiy ha scritto:
>>> >> Please comment. Thanks.
>> >
>> > Good, but S-o-b in patch 3 is missing.
>
> Why does it matter? It is your patch, it will go through someone else's
> tree and I just reposted it - I could have added "Reviewed-by" or
> "Tested-by" or "Acked-by", but SOB...

Your employer might not allow you to pick up other's patches.  SOB tells 
that, among other things.

Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
> 
> This is a first step towards QOMifying /machine.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

I got interesting conversation about "sob" in my team so here it is:

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Is that enough or I better repost the patch?
May be patchworks will pick it as it does for "RB" and other "by"'s.


> ---
>  include/hw/boards.h | 1 +
>  vl.c                | 5 +++++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index c2096e6..8640272 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -29,6 +29,7 @@ struct QEMUMachine {
>      const char *name;
>      const char *alias;
>      const char *desc;
> +    const char *class_name;
>      QEMUMachineInitFunc *init;
>      QEMUMachineResetFunc *reset;
>      QEMUMachineHotAddCPUFunc *hot_add_cpu;
> diff --git a/vl.c b/vl.c
> index 01ab7e4..b300721 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4034,6 +4034,11 @@ int main(int argc, char **argv, char **envp)
>          qtest_init(qtest_chrdev, qtest_log);
>      }
>  
> +    if (machine->class_name) {
> +        Object *m = object_new(machine->class_name);
> +        object_property_add_child(object_get_root(), "machine", m, NULL);
> +    }
> +
>      machine_opts = qemu_get_machine_opts();
>      kernel_filename = qemu_opt_get(machine_opts, "kernel");
>      initrd_filename = qemu_opt_get(machine_opts, "initrd");
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 21/02/2014 04:04, Alexey Kardashevskiy ha scritto:
> On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
>> > From: Paolo Bonzini <pbonzini@redhat.com>
>> >
>> > This is a first step towards QOMifying /machine.
>> >
>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> I got interesting conversation about "sob" in my team so here it is:
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> Is that enough or I better repost the patch?
> May be patchworks will pick it as it does for "RB" and other "by"'s.
>
>

Yeah, this is fine.

Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 02/21/2014 09:30 PM, Paolo Bonzini wrote:
> Il 21/02/2014 04:04, Alexey Kardashevskiy ha scritto:
>> On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
>>> > From: Paolo Bonzini <pbonzini@redhat.com>
>>> >
>>> > This is a first step towards QOMifying /machine.
>>> >
>>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> I got interesting conversation about "sob" in my team so here it is:
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>
>> Is that enough or I better repost the patch?
>> May be patchworks will pick it as it does for "RB" and other "by"'s.
>>
>>
> 
> Yeah, this is fine.


So what is next?


-- 
ps. I like this project and my current job very much but if my employer did
not pay me for that, it would be really hard to find motivation to post
fixes for QEMU - always takes ages...

Alexey

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Markus Armbruster]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> On 02/21/2014 09:30 PM, Paolo Bonzini wrote:
>> Il 21/02/2014 04:04, Alexey Kardashevskiy ha scritto:
>>> On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
>>>> > From: Paolo Bonzini <pbonzini@redhat.com>
>>>> >
>>>> > This is a first step towards QOMifying /machine.
>>>> >
>>>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>> I got interesting conversation about "sob" in my team so here it is:
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>
>>> Is that enough or I better repost the patch?
>>> May be patchworks will pick it as it does for "RB" and other "by"'s.
>>>
>>>
>> 
>> Yeah, this is fine.
>
>
> So what is next?

If it doesn't get picked up in a reasonable time frame despite your
ping, you repost.

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Andreas Färber]

Am 20.02.2014 14:58, schrieb Paolo Bonzini:
> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>> From: Paolo Bonzini <pbonzini@redhat.com>
>>
>> This is a first step towards QOMifying /machine.
>>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> The patch was originally mine, so I could get it in if Andreas wants me
> to handle patches 2-3.  But for anyone else it would be missing your
> S-o-b line.

With this patch I have been plagued by doubts of whether we can run into
a race of creating /machine through qdev_get_machine() via command line
option handling or whatever other code paths. I'm at a conference and
did not find time yet to test this out - if you two could investigate
and clarify, that would be helpful in moving forward.

Also I thought that someone else had looked into replacing the whole of
machine_init and QEMUMachine with QOM infrastructure? Anyway it was an
idea that I once had, Anthony didn't like at first and then someone else
(Luiz?) convinced Anthony to do it after all but then somehow it got
stuck with no patches posted... The discussed approach was instead of
creating a type in machine init depending on some
QEMUMachine::class_name, always create the type. But either approach
conflicts with creating /machine as Container type, as mentioned above.
If we go with such an interim solution then at least qdev.c needs to
grow an assert.

Regards,
Andreas

> 
> Paolo
> 
>> ---
>>  include/hw/boards.h | 1 +
>>  vl.c                | 5 +++++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/include/hw/boards.h b/include/hw/boards.h
>> index c2096e6..8640272 100644
>> --- a/include/hw/boards.h
>> +++ b/include/hw/boards.h
>> @@ -29,6 +29,7 @@ struct QEMUMachine {
>>      const char *name;
>>      const char *alias;
>>      const char *desc;
>> +    const char *class_name;
>>      QEMUMachineInitFunc *init;
>>      QEMUMachineResetFunc *reset;
>>      QEMUMachineHotAddCPUFunc *hot_add_cpu;
>> diff --git a/vl.c b/vl.c
>> index 01ab7e4..b300721 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4034,6 +4034,11 @@ int main(int argc, char **argv, char **envp)
>>          qtest_init(qtest_chrdev, qtest_log);
>>      }
>>
>> +    if (machine->class_name) {
>> +        Object *m = object_new(machine->class_name);
>> +        object_property_add_child(object_get_root(), "machine", m,
>> NULL);
>> +    }
>> +
>>      machine_opts = qemu_get_machine_opts();
>>      kernel_filename = qemu_opt_get(machine_opts, "kernel");
>>      initrd_filename = qemu_opt_get(machine_opts, "initrd");
>>
> 
> 


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

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 27/02/2014 11:34, Andreas Färber ha scritto:
> Am 20.02.2014 14:58, schrieb Paolo Bonzini:
>> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>>> From: Paolo Bonzini <pbonzini@redhat.com>
>>>
>>> This is a first step towards QOMifying /machine.
>>>
>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>
>> The patch was originally mine, so I could get it in if Andreas wants me
>> to handle patches 2-3.  But for anyone else it would be missing your
>> S-o-b line.
>
> With this patch I have been plagued by doubts of whether we can run into
> a race of creating /machine through qdev_get_machine() via command line
> option handling or whatever other code paths. I'm at a conference and
> did not find time yet to test this out - if you two could investigate
> and clarify, that would be helpful in moving forward.
>
> Also I thought that someone else had looked into replacing the whole of
> machine_init and QEMUMachine with QOM infrastructure?

Yes, that was Marcel.

I think that Alexey's patch and Marcel's approach are just two different 
parts of the same project.

Marcel's is more general and focused on option handling, and the main 
idea is to convert -machine suboptions to properties.  Alexey's is 
instead focused on using the QOM tree and the "contained-in" 
relationship as a basis for providing machine-specific (and possibly 
SoC-specific) hooks.

Each of them highlights one of the two aspects that, in my opinion, make 
QOM interesting (respectively, unification of interfaces and the 
containment tree).

Paolo

> Anyway it was an
> idea that I once had, Anthony didn't like at first and then someone else
> (Luiz?) convinced Anthony to do it after all but then somehow it got
> stuck with no patches posted... The discussed approach was instead of
> creating a type in machine init depending on some
> QEMUMachine::class_name, always create the type. But either approach
> conflicts with creating /machine as Container type, as mentioned above.
> If we go with such an interim solution then at least qdev.c needs to
> grow an assert.

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 02/27/2014 06:44 PM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> On 02/21/2014 09:30 PM, Paolo Bonzini wrote:
>>> Il 21/02/2014 04:04, Alexey Kardashevskiy ha scritto:
>>>> On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
>>>>>> From: Paolo Bonzini <pbonzini@redhat.com>
>>>>>>
>>>>>> This is a first step towards QOMifying /machine.
>>>>>>
>>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>> I got interesting conversation about "sob" in my team so here it is:
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>
>>>> Is that enough or I better repost the patch?
>>>> May be patchworks will pick it as it does for "RB" and other "by"'s.
>>>>
>>>>
>>>
>>> Yeah, this is fine.
>>
>>
>> So what is next?
> 
> If it doesn't get picked up in a reasonable time frame despite your
> ping, you repost.

Lately I am having serious doubts that I correctly understand what the
reasonable time frame is. How much do I wait till repost?



-- 
Alexey

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Markus Armbruster]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> On 02/27/2014 06:44 PM, Markus Armbruster wrote:
>> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
>> 
>>> On 02/21/2014 09:30 PM, Paolo Bonzini wrote:
>>>> Il 21/02/2014 04:04, Alexey Kardashevskiy ha scritto:
>>>>> On 02/21/2014 12:50 AM, Alexey Kardashevskiy wrote:
>>>>>>> From: Paolo Bonzini <pbonzini@redhat.com>
>>>>>>>
>>>>>>> This is a first step towards QOMifying /machine.
>>>>>>>
>>>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>>> I got interesting conversation about "sob" in my team so here it is:
>>>>>
>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>
>>>>> Is that enough or I better repost the patch?
>>>>> May be patchworks will pick it as it does for "RB" and other "by"'s.
>>>>>
>>>>>
>>>>
>>>> Yeah, this is fine.
>>>
>>>
>>> So what is next?
>> 
>> If it doesn't get picked up in a reasonable time frame despite your
>> ping, you repost.
>
> Lately I am having serious doubts that I correctly understand what the
> reasonable time frame is. How much do I wait till repost?

I guess a ping after a week or two without progress is fair.  Repost
after it expired from patches (four weeks?), or when it doesn't apply
anymore.

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Marcel Apfelbaum]

On Thu, 2014-02-27 at 11:41 +0100, Paolo Bonzini wrote:
> Il 27/02/2014 11:34, Andreas Färber ha scritto:
> > Am 20.02.2014 14:58, schrieb Paolo Bonzini:
> >> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
> >>> From: Paolo Bonzini <pbonzini@redhat.com>
> >>>
> >>> This is a first step towards QOMifying /machine.
> >>>
> >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >>
> >> The patch was originally mine, so I could get it in if Andreas wants me
> >> to handle patches 2-3.  But for anyone else it would be missing your
> >> S-o-b line.
> >
> > With this patch I have been plagued by doubts of whether we can run into
> > a race of creating /machine through qdev_get_machine() via command line
> > option handling or whatever other code paths.
I'd like to understand this issue, can anybody elaborate a little on the possible race?

>  I'm at a conference and
> > did not find time yet to test this out - if you two could investigate
> > and clarify, that would be helpful in moving forward.
> >
> > Also I thought that someone else had looked into replacing the whole of
> > machine_init and QEMUMachine with QOM infrastructure?
> 
> Yes, that was Marcel.
Yes, I am working on that and planning to send an RFC V2 really soon.
> 
> I think that Alexey's patch and Marcel's approach are just two different 
> parts of the same project.
> 
> Marcel's is more general and focused on option handling, and the main 
> idea is to convert -machine suboptions to properties.  Alexey's is 
> instead focused on using the QOM tree and the "contained-in" 
> relationship as a basis for providing machine-specific (and possibly 
> SoC-specific) hooks.
> 
> Each of them highlights one of the two aspects that, in my opinion, make 
> QOM interesting (respectively, unification of interfaces and the 
> containment tree).

I was planning to tackle the replacement of the machine from a container
to an actual object too, however this patch conflicts with my
series because I already have a QOM Machine object created *always*
and this patch adds another object *sometimes*.

Is this patch's functionality in use yet? Any idea how to merge those ideas?

> Paolo
> 
> > Anyway it was an
> > idea that I once had, Anthony didn't like at first and then someone else
> > (Luiz?) convinced Anthony to do it after all but then somehow it got
> > stuck with no patches posted... The discussed approach was instead of
> > creating a type in machine init depending on some
> > QEMUMachine::class_name, always create the type. But either approach
> > conflicts with creating /machine as Container type, as mentioned above.
As I am going with the *always* approach and hoping to replace /machine
with a QOM object, what is the conflict here?

Thanks,
Marcel

> > If we go with such an interim solution then at least qdev.c needs to
> > grow an assert.
> 
> 

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>> >
>> > Each of them highlights one of the two aspects that, in my opinion, make
>> > QOM interesting (respectively, unification of interfaces and the
>> > containment tree).
> I was planning to tackle the replacement of the machine from a container
> to an actual object too, however this patch conflicts with my
> series because I already have a QOM Machine object created *always*
> and this patch adds another object *sometimes*.
>
> Is this patch's functionality in use yet? Any idea how to merge those ideas?

pseries simply wants to make /machine implement the FWPathProvider 
interface.  As long as you have a way for boards to specify a TypeInfo 
for /machine, this patch will not get in the way.

Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Marcel Apfelbaum]

On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
> >> >
> >> > Each of them highlights one of the two aspects that, in my opinion, make
> >> > QOM interesting (respectively, unification of interfaces and the
> >> > containment tree).
> > I was planning to tackle the replacement of the machine from a container
> > to an actual object too, however this patch conflicts with my
> > series because I already have a QOM Machine object created *always*
> > and this patch adds another object *sometimes*.
> >
> > Is this patch's functionality in use yet? Any idea how to merge those ideas?
> 
> pseries simply wants to make /machine implement the FWPathProvider 
> interface.  As long as you have a way for boards to specify a TypeInfo 
> for /machine, this patch will not get in the way.
Thanks Paolo! I'll be aware not to brake this functionality.
Marcel

> 
> Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>
>>>>> Each of them highlights one of the two aspects that, in my opinion, make
>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>> containment tree).
>>> I was planning to tackle the replacement of the machine from a container
>>> to an actual object too, however this patch conflicts with my
>>> series because I already have a QOM Machine object created *always*
>>> and this patch adds another object *sometimes*.
>>>
>>> Is this patch's functionality in use yet? Any idea how to merge those ideas?
>>
>> pseries simply wants to make /machine implement the FWPathProvider 
>> interface.  As long as you have a way for boards to specify a TypeInfo 
>> for /machine, this patch will not get in the way.
> Thanks Paolo! I'll be aware not to brake this functionality.
> Marcel

What is the outcome of this discussion for the patches I posted? Do I have
to wait till you finish that machine properties rework and repost or...?
Thanks.



-- 
Alexey

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
> On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
>> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>>
>>>>>> Each of them highlights one of the two aspects that, in my opinion, make
>>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>>> containment tree).
>>>> I was planning to tackle the replacement of the machine from a container
>>>> to an actual object too, however this patch conflicts with my
>>>> series because I already have a QOM Machine object created *always*
>>>> and this patch adds another object *sometimes*.
>>>>
>>>> Is this patch's functionality in use yet? Any idea how to merge those ideas?
>>>
>>> pseries simply wants to make /machine implement the FWPathProvider
>>> interface.  As long as you have a way for boards to specify a TypeInfo
>>> for /machine, this patch will not get in the way.
>> Thanks Paolo! I'll be aware not to brake this functionality.
>> Marcel
>
> What is the outcome of this discussion for the patches I posted? Do I have
> to wait till you finish that machine properties rework and repost or...?

Your patches are fine.  Who gets in first, wins.  The other, rebases. :)

Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
> Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
>> On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
>>> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>>>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>>>
>>>>>>> Each of them highlights one of the two aspects that, in my opinion,
>>>>>>> make
>>>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>>>> containment tree).
>>>>> I was planning to tackle the replacement of the machine from a container
>>>>> to an actual object too, however this patch conflicts with my
>>>>> series because I already have a QOM Machine object created *always*
>>>>> and this patch adds another object *sometimes*.
>>>>>
>>>>> Is this patch's functionality in use yet? Any idea how to merge those
>>>>> ideas?
>>>>
>>>> pseries simply wants to make /machine implement the FWPathProvider
>>>> interface.  As long as you have a way for boards to specify a TypeInfo
>>>> for /machine, this patch will not get in the way.
>>> Thanks Paolo! I'll be aware not to brake this functionality.
>>> Marcel
>>
>> What is the outcome of this discussion for the patches I posted? Do I have
>> to wait till you finish that machine properties rework and repost or...?
> 
> Your patches are fine.  Who gets in first, wins.  The other, rebases. :)


Ok. Understood. Wait and rebase and repost and repeat. Ok ;) Thanks.


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Andreas Färber]

Am 28.02.2014 16:08, schrieb Alexey Kardashevskiy:
> On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
>> Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
>>> On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
>>>> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>>>>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>>>>
>>>>>>>> Each of them highlights one of the two aspects that, in my opinion,
>>>>>>>> make
>>>>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>>>>> containment tree).
>>>>>> I was planning to tackle the replacement of the machine from a container
>>>>>> to an actual object too, however this patch conflicts with my
>>>>>> series because I already have a QOM Machine object created *always*
>>>>>> and this patch adds another object *sometimes*.
>>>>>>
>>>>>> Is this patch's functionality in use yet? Any idea how to merge those
>>>>>> ideas?
>>>>>
>>>>> pseries simply wants to make /machine implement the FWPathProvider
>>>>> interface.  As long as you have a way for boards to specify a TypeInfo
>>>>> for /machine, this patch will not get in the way.
>>>> Thanks Paolo! I'll be aware not to brake this functionality.
>>>> Marcel
>>>
>>> What is the outcome of this discussion for the patches I posted? Do I have
>>> to wait till you finish that machine properties rework and repost or...?
>>
>> Your patches are fine.

I disputed that in this case and asked for a code change in qdev code
either not creating the container and/or asserting that that code path
is not hit.

>>  Who gets in first, wins.  The other, rebases. :)

Negative, qemu.git is not a tombola. If there's known issues they need
to be fixed before merging. But yes, when there's two "good" approaches
then it's a matter of merge order, which ideally should involve
communication rather than competition among maintainers. Because the
pull that does not apply then gets bounced by Peter.

> Ok. Understood. Wait and rebase and repost and repeat. Ok ;) Thanks.

A problem here and elsewhere in your series is that it's a mix of
changes to generic code and ppc code, with the cover letter indicating
it's a ppc series. ppc series I usually leave for Alex to review, and
Alex is on travels for a few more weeks to come.

So for those of your patches that I'm aware of - -cpu, FWPathProvider
and this /machine most likely I will pick up the generic parts for the
QOM devices tree after having tested some more corner cases, to get them
into 2.0.

For ppc-next I know that Alex is strictly running a virt-test testsuite
and whenever something in his queue is broken somewhere, the whole queue
gets delayed until the fault is found and fixed or dropped.

Regards,
Andreas

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

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 28/02/2014 16:57, Andreas Färber ha scritto:
> Am 28.02.2014 16:08, schrieb Alexey Kardashevskiy:
>> On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
>>> Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
>>>> On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
>>>>> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>>>>>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>>>>>
>>>>>>>>> Each of them highlights one of the two aspects that, in my opinion,
>>>>>>>>> make
>>>>>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>>>>>> containment tree).
>>>>>>> I was planning to tackle the replacement of the machine from a container
>>>>>>> to an actual object too, however this patch conflicts with my
>>>>>>> series because I already have a QOM Machine object created *always*
>>>>>>> and this patch adds another object *sometimes*.
>>>>>>>
>>>>>>> Is this patch's functionality in use yet? Any idea how to merge those
>>>>>>> ideas?
>>>>>>
>>>>>> pseries simply wants to make /machine implement the FWPathProvider
>>>>>> interface.  As long as you have a way for boards to specify a TypeInfo
>>>>>> for /machine, this patch will not get in the way.
>>>>> Thanks Paolo! I'll be aware not to brake this functionality.
>>>>> Marcel
>>>>
>>>> What is the outcome of this discussion for the patches I posted? Do I have
>>>> to wait till you finish that machine properties rework and repost or...?
>>>
>>> Your patches are fine.
>
> I disputed that in this case and asked for a code change in qdev code
> either not creating the container and/or asserting that that code path
> is not hit.

You're right.  The outcome of the discussion was not that the patches 
are fine, but rather that they need not be blocked by Marcel's work.  I 
was too terse/vague/wrong---sorry.

>>>  Who gets in first, wins.  The other, rebases. :)
>
> Negative, qemu.git is not a tombola. If there's known issues they need
> to be fixed before merging. But yes, when there's two "good" approaches
> then it's a matter of merge order, which ideally should involve
> communication rather than competition among maintainers. Because the
> pull that does not apply then gets bounced by Peter.

Right, hence the smiley.  People that submit patches should be aware of 
conflicting series and tell the maintainers about it.

Paolo

Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Alexey Kardashevskiy]

On 03/01/2014 02:57 AM, Andreas Färber wrote:
> Am 28.02.2014 16:08, schrieb Alexey Kardashevskiy:
>> On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
>>> Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
>>>> On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
>>>>> On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
>>>>>> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
>>>>>>>>>
>>>>>>>>> Each of them highlights one of the two aspects that, in my opinion,
>>>>>>>>> make
>>>>>>>>> QOM interesting (respectively, unification of interfaces and the
>>>>>>>>> containment tree).
>>>>>>> I was planning to tackle the replacement of the machine from a container
>>>>>>> to an actual object too, however this patch conflicts with my
>>>>>>> series because I already have a QOM Machine object created *always*
>>>>>>> and this patch adds another object *sometimes*.
>>>>>>>
>>>>>>> Is this patch's functionality in use yet? Any idea how to merge those
>>>>>>> ideas?
>>>>>>
>>>>>> pseries simply wants to make /machine implement the FWPathProvider
>>>>>> interface.  As long as you have a way for boards to specify a TypeInfo
>>>>>> for /machine, this patch will not get in the way.
>>>>> Thanks Paolo! I'll be aware not to brake this functionality.
>>>>> Marcel
>>>>
>>>> What is the outcome of this discussion for the patches I posted? Do I have
>>>> to wait till you finish that machine properties rework and repost or...?
>>>
>>> Your patches are fine.
> 
> I disputed that in this case and asked for a code change in qdev code
> either not creating the container and/or asserting that that code path
> is not hit.
> 
>>>  Who gets in first, wins.  The other, rebases. :)
> 
> Negative, qemu.git is not a tombola. If there's known issues they need
> to be fixed before merging. But yes, when there's two "good" approaches
> then it's a matter of merge order, which ideally should involve
> communication rather than competition among maintainers. Because the
> pull that does not apply then gets bounced by Peter.
> 
>> Ok. Understood. Wait and rebase and repost and repeat. Ok ;) Thanks.
> 
> A problem here and elsewhere in your series is that it's a mix of
> changes to generic code and ppc code, with the cover letter indicating
> it's a ppc series. ppc series I usually leave for Alex to review, and
> Alex is on travels for a few more weeks to come.


I still do not entirely understand.

In this series, 1/6 is not really platform dependent but it is still for
Alex to review?

4/6 is about hw/net/spapr_llan.c which is not in hw/ppc/ so it does not
have to be Alex, no?

5/6 is about hw/ppc/spapr_vio.c which is in hw/ppc/ but it is rather QOM
than PPC - still, Alex?

If anyone RB'd or Ack'ed any of those, would it help? Would it help if I
split my patchsets into two (ppc and independent) and post them separately?


Or it always Alex and since I screwed up in the beginning (I know I did,
and I probably keep screwing, sorry for that), I am in very low priority
queue forever?



> So for those of your patches that I'm aware of - -cpu, FWPathProvider
> and this /machine most likely I will pick up the generic parts for the
> QOM devices tree after having tested some more corner cases, to get them
> into 2.0.
> 
> For ppc-next I know that Alex is strictly running a virt-test testsuite
> and whenever something in his queue is broken somewhere, the whole queue
> gets delayed until the fault is found and fixed or dropped.



-- 
Alexey

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Andreas Färber]

Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
> QEMU supports firmware names for all devices in the QEMU tree but
> some architectures expect some parts of firmware path names in different
> format.
> 
> This introduces a firmware-pathname-change interface definition.
> If some machines needs to redefine the firmware path format, it has
> to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
> the device on the QOM tree (typically /machine).
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

I do not see a reply to my question on v4 and didn't catch bonzini on
IRC - guessing the two lines should be swapped since both v4 and v5 were
submitted by Alexey?

> ---
> Changes:
> v5:
> * fixed code design
> * added license headers
> 
> v4:
> * added fw-path-provider.o into tests/Makefile
> * fixed 80chars warning from checkpatch.pl
> ---
>  hw/core/Makefile.objs         |  1 +
>  hw/core/fw-path-provider.c    | 51 +++++++++++++++++++++++++++++++++++++++++++
>  hw/core/qdev.c                | 18 ++++++++++++++-
>  include/hw/fw-path-provider.h | 49 +++++++++++++++++++++++++++++++++++++++++
>  tests/Makefile                |  1 +
>  5 files changed, 119 insertions(+), 1 deletion(-)
>  create mode 100644 hw/core/fw-path-provider.c
>  create mode 100644 include/hw/fw-path-provider.h
> 
> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
> index 9e324be..9f75ea3 100644
> --- a/hw/core/Makefile.objs
> +++ b/hw/core/Makefile.objs
> @@ -1,5 +1,6 @@
>  # core qdev-related obj files, also used by *-user:
>  common-obj-y += qdev.o qdev-properties.o
> +common-obj-y += fw-path-provider.o
>  # irq.o needed for qdev GPIO handling:
>  common-obj-y += irq.o
>  common-obj-y += hotplug.o
> diff --git a/hw/core/fw-path-provider.c b/hw/core/fw-path-provider.c
> new file mode 100644
> index 0000000..b117157
> --- /dev/null
> +++ b/hw/core/fw-path-provider.c
> @@ -0,0 +1,51 @@
> +/*
> + *  Firmware patch provider class and helpers.
> + *
> + *  This program 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; under version 2 of the License.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include "hw/fw-path-provider.h"
> +
> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
> +                                    DeviceState *dev)
> +{
> +    FWPathProviderClass *k = FW_PATH_PROVIDER_GET_CLASS(p);
> +
> +    return k->get_dev_path(p, bus, dev);
> +}
> +
> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
> +                                        DeviceState *dev)
> +{
> +    FWPathProvider *p = (FWPathProvider *)
> +        object_dynamic_cast(o, TYPE_FW_PATH_PROVIDER);
> +
> +    if (p) {
> +        return fw_path_provider_get_dev_path(p, bus, dev);
> +    }
> +
> +    return NULL;
> +}
> +
> +static const TypeInfo fw_path_provider_info = {
> +    .name          = TYPE_FW_PATH_PROVIDER,
> +    .parent        = TYPE_INTERFACE,
> +    .class_size    = sizeof(FWPathProviderClass),
> +};
> +
> +static void fw_path_provider_register_types(void)
> +{
> +    type_register_static(&fw_path_provider_info);
> +}
> +
> +type_init(fw_path_provider_register_types)
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index ae30163..dd993b5 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -26,6 +26,7 @@
>     this API directly.  */
>  
>  #include "hw/qdev.h"
> +#include "hw/fw-path-provider.h"
>  #include "sysemu/sysemu.h"
>  #include "qapi/error.h"
>  #include "qapi/qmp/qerror.h"
> @@ -529,6 +530,18 @@ static char *bus_get_fw_dev_path(BusState *bus, DeviceState *dev)
>      return NULL;
>  }
>  
> +static char *qdev_get_fw_dev_path_from_handler(BusState *bus, DeviceState *dev)
> +{
> +    Object *obj = OBJECT(dev);
> +    char *d = NULL;
> +
> +    while (!d && obj->parent) {
> +        obj = obj->parent;
> +        d = fw_path_provider_try_get_dev_path(obj, bus, dev);
> +    }
> +    return d;
> +}
> +
>  static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>  {
>      int l = 0;
> @@ -536,7 +549,10 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>      if (dev && dev->parent_bus) {
>          char *d;
>          l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
> -        d = bus_get_fw_dev_path(dev->parent_bus, dev);
> +        d = qdev_get_fw_dev_path_from_handler(dev->parent_bus, dev);
> +        if (!d) {
> +            d = bus_get_fw_dev_path(dev->parent_bus, dev);
> +        }
>          if (d) {
>              l += snprintf(p + l, size - l, "%s", d);
>              g_free(d);
> diff --git a/include/hw/fw-path-provider.h b/include/hw/fw-path-provider.h
> new file mode 100644
> index 0000000..8889d8b
> --- /dev/null
> +++ b/include/hw/fw-path-provider.h
> @@ -0,0 +1,49 @@
> +/*
> + *  Firmware patch provider class and helpers definitions.
> + *
> + *  This program 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; under version 2 of the License.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef FW_PATH_PROVIDER_H
> +#define FW_PATH_PROVIDER_H 1
> +
> +#include "qemu-common.h"
> +#include "qom/object.h"
> +
> +#define TYPE_FW_PATH_PROVIDER "fw-path-provider"
> +
> +#define FW_PATH_PROVIDER_CLASS(klass) \
> +     OBJECT_CLASS_CHECK(FWPathProviderClass, (klass), TYPE_FW_PATH_PROVIDER)
> +#define FW_PATH_PROVIDER_GET_CLASS(obj) \
> +    OBJECT_GET_CLASS(FWPathProviderClass, (obj), TYPE_FW_PATH_PROVIDER)
> +#define FW_PATH_PROVIDER(obj) \
> +     INTERFACE_CHECK(FWPathProvider, (obj), TYPE_FW_PATH_PROVIDER)
> +
> +typedef struct FWPathProvider {
> +    Object parent_obj;
> +} FWPathProvider;

Unused?

> +
> +typedef void (*StreamCanPushNotifyFn)(void *opaque);

Unused?

Hoping we can consider this a bugfix and get done during freeze.

Andreas

> +
> +typedef struct FWPathProviderClass {
> +    InterfaceClass parent_class;
> +
> +    char *(*get_dev_path)(FWPathProvider *p, BusState *bus, DeviceState *dev);
> +} FWPathProviderClass;
> +
> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
> +                                    DeviceState *dev);
> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
> +                                        DeviceState *dev);
> +
> +#endif /* FW_PATH_PROVIDER_H */
> diff --git a/tests/Makefile b/tests/Makefile
> index 9a7d2f1..0692b11 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -165,6 +165,7 @@ tests/test-int128$(EXESUF): tests/test-int128.o
>  tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \
>  	hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\
>  	hw/core/irq.o \
> +	hw/core/fw-path-provider.o \
>  	$(qom-core-obj) \
>  	$(test-qapi-obj-y) \
>  	libqemuutil.a libqemustub.a
> 


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

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Paolo Bonzini]

Il 12/03/2014 19:07, Andreas Färber ha scritto:
> Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
>> > QEMU supports firmware names for all devices in the QEMU tree but
>> > some architectures expect some parts of firmware path names in different
>> > format.
>> >
>> > This introduces a firmware-pathname-change interface definition.
>> > If some machines needs to redefine the firmware path format, it has
>> > to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
>> > the device on the QOM tree (typically /machine).
>> >
>> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> I do not see a reply to my question on v4 and didn't catch bonzini on
> IRC - guessing the two lines should be swapped since both v4 and v5 were
> submitted by Alexey?
>

Yeah, you can swap them.  We worked on it together.

Paolo

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Alexey Kardashevskiy]

On 03/13/2014 05:07 AM, Andreas Färber wrote:
> Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
>> QEMU supports firmware names for all devices in the QEMU tree but
>> some architectures expect some parts of firmware path names in different
>> format.
>>
>> This introduces a firmware-pathname-change interface definition.
>> If some machines needs to redefine the firmware path format, it has
>> to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
>> the device on the QOM tree (typically /machine).
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> I do not see a reply to my question on v4 and didn't catch bonzini on
> IRC - guessing the two lines should be swapped since both v4 and v5 were
> submitted by Alexey?


I am actually waiting till machine QOM'fication to finish, then I'll repost
this patchset. Something changed?


>> ---
>> Changes:
>> v5:
>> * fixed code design
>> * added license headers
>>
>> v4:
>> * added fw-path-provider.o into tests/Makefile
>> * fixed 80chars warning from checkpatch.pl
>> ---
>>  hw/core/Makefile.objs         |  1 +
>>  hw/core/fw-path-provider.c    | 51 +++++++++++++++++++++++++++++++++++++++++++
>>  hw/core/qdev.c                | 18 ++++++++++++++-
>>  include/hw/fw-path-provider.h | 49 +++++++++++++++++++++++++++++++++++++++++
>>  tests/Makefile                |  1 +
>>  5 files changed, 119 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/core/fw-path-provider.c
>>  create mode 100644 include/hw/fw-path-provider.h
>>
>> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
>> index 9e324be..9f75ea3 100644
>> --- a/hw/core/Makefile.objs
>> +++ b/hw/core/Makefile.objs
>> @@ -1,5 +1,6 @@
>>  # core qdev-related obj files, also used by *-user:
>>  common-obj-y += qdev.o qdev-properties.o
>> +common-obj-y += fw-path-provider.o
>>  # irq.o needed for qdev GPIO handling:
>>  common-obj-y += irq.o
>>  common-obj-y += hotplug.o
>> diff --git a/hw/core/fw-path-provider.c b/hw/core/fw-path-provider.c
>> new file mode 100644
>> index 0000000..b117157
>> --- /dev/null
>> +++ b/hw/core/fw-path-provider.c
>> @@ -0,0 +1,51 @@
>> +/*
>> + *  Firmware patch provider class and helpers.
>> + *
>> + *  This program 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; under version 2 of the License.
>> + *
>> + *  This program is distributed in the hope that it will be useful,
>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *  GNU General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License
>> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include "hw/fw-path-provider.h"
>> +
>> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
>> +                                    DeviceState *dev)
>> +{
>> +    FWPathProviderClass *k = FW_PATH_PROVIDER_GET_CLASS(p);
>> +
>> +    return k->get_dev_path(p, bus, dev);
>> +}
>> +
>> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
>> +                                        DeviceState *dev)
>> +{
>> +    FWPathProvider *p = (FWPathProvider *)
>> +        object_dynamic_cast(o, TYPE_FW_PATH_PROVIDER);
>> +
>> +    if (p) {
>> +        return fw_path_provider_get_dev_path(p, bus, dev);
>> +    }
>> +
>> +    return NULL;
>> +}
>> +
>> +static const TypeInfo fw_path_provider_info = {
>> +    .name          = TYPE_FW_PATH_PROVIDER,
>> +    .parent        = TYPE_INTERFACE,
>> +    .class_size    = sizeof(FWPathProviderClass),
>> +};
>> +
>> +static void fw_path_provider_register_types(void)
>> +{
>> +    type_register_static(&fw_path_provider_info);
>> +}
>> +
>> +type_init(fw_path_provider_register_types)
>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>> index ae30163..dd993b5 100644
>> --- a/hw/core/qdev.c
>> +++ b/hw/core/qdev.c
>> @@ -26,6 +26,7 @@
>>     this API directly.  */
>>  
>>  #include "hw/qdev.h"
>> +#include "hw/fw-path-provider.h"
>>  #include "sysemu/sysemu.h"
>>  #include "qapi/error.h"
>>  #include "qapi/qmp/qerror.h"
>> @@ -529,6 +530,18 @@ static char *bus_get_fw_dev_path(BusState *bus, DeviceState *dev)
>>      return NULL;
>>  }
>>  
>> +static char *qdev_get_fw_dev_path_from_handler(BusState *bus, DeviceState *dev)
>> +{
>> +    Object *obj = OBJECT(dev);
>> +    char *d = NULL;
>> +
>> +    while (!d && obj->parent) {
>> +        obj = obj->parent;
>> +        d = fw_path_provider_try_get_dev_path(obj, bus, dev);
>> +    }
>> +    return d;
>> +}
>> +
>>  static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>>  {
>>      int l = 0;
>> @@ -536,7 +549,10 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>>      if (dev && dev->parent_bus) {
>>          char *d;
>>          l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
>> -        d = bus_get_fw_dev_path(dev->parent_bus, dev);
>> +        d = qdev_get_fw_dev_path_from_handler(dev->parent_bus, dev);
>> +        if (!d) {
>> +            d = bus_get_fw_dev_path(dev->parent_bus, dev);
>> +        }
>>          if (d) {
>>              l += snprintf(p + l, size - l, "%s", d);
>>              g_free(d);
>> diff --git a/include/hw/fw-path-provider.h b/include/hw/fw-path-provider.h
>> new file mode 100644
>> index 0000000..8889d8b
>> --- /dev/null
>> +++ b/include/hw/fw-path-provider.h
>> @@ -0,0 +1,49 @@
>> +/*
>> + *  Firmware patch provider class and helpers definitions.
>> + *
>> + *  This program 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; under version 2 of the License.
>> + *
>> + *  This program is distributed in the hope that it will be useful,
>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *  GNU General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License
>> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef FW_PATH_PROVIDER_H
>> +#define FW_PATH_PROVIDER_H 1
>> +
>> +#include "qemu-common.h"
>> +#include "qom/object.h"
>> +
>> +#define TYPE_FW_PATH_PROVIDER "fw-path-provider"
>> +
>> +#define FW_PATH_PROVIDER_CLASS(klass) \
>> +     OBJECT_CLASS_CHECK(FWPathProviderClass, (klass), TYPE_FW_PATH_PROVIDER)
>> +#define FW_PATH_PROVIDER_GET_CLASS(obj) \
>> +    OBJECT_GET_CLASS(FWPathProviderClass, (obj), TYPE_FW_PATH_PROVIDER)
>> +#define FW_PATH_PROVIDER(obj) \
>> +     INTERFACE_CHECK(FWPathProvider, (obj), TYPE_FW_PATH_PROVIDER)
>> +
>> +typedef struct FWPathProvider {
>> +    Object parent_obj;
>> +} FWPathProvider;
> 
> Unused?
> 
>> +
>> +typedef void (*StreamCanPushNotifyFn)(void *opaque);
> 
> Unused?
> 
> Hoping we can consider this a bugfix and get done during freeze.
> 
> Andreas
> 
>> +
>> +typedef struct FWPathProviderClass {
>> +    InterfaceClass parent_class;
>> +
>> +    char *(*get_dev_path)(FWPathProvider *p, BusState *bus, DeviceState *dev);
>> +} FWPathProviderClass;
>> +
>> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
>> +                                    DeviceState *dev);
>> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
>> +                                        DeviceState *dev);
>> +
>> +#endif /* FW_PATH_PROVIDER_H */
>> diff --git a/tests/Makefile b/tests/Makefile
>> index 9a7d2f1..0692b11 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -165,6 +165,7 @@ tests/test-int128$(EXESUF): tests/test-int128.o
>>  tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \
>>  	hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\
>>  	hw/core/irq.o \
>> +	hw/core/fw-path-provider.o \
>>  	$(qom-core-obj) \
>>  	$(test-qapi-obj-y) \
>>  	libqemuutil.a libqemustub.a
>>
> 
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Andreas Färber]

Am 13.03.2014 00:02, schrieb Alexey Kardashevskiy:
> On 03/13/2014 05:07 AM, Andreas Färber wrote:
>> Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
>>> QEMU supports firmware names for all devices in the QEMU tree but
>>> some architectures expect some parts of firmware path names in different
>>> format.
>>>
>>> This introduces a firmware-pathname-change interface definition.
>>> If some machines needs to redefine the firmware path format, it has
>>> to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
>>> the device on the QOM tree (typically /machine).
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>
>> I do not see a reply to my question on v4 and didn't catch bonzini on
>> IRC - guessing the two lines should be swapped since both v4 and v5 were
>> submitted by Alexey?
> 
> 
> I am actually waiting till machine QOM'fication to finish, then I'll repost
> this patchset. Something changed?

Yes, machine QOM'ification is queued on qom-next and the pull request
containing it is facing some issues still. But you can already rebase
onto git://github.com/afaerber/qemu-cpu.git qom-next branch.

In short, the pseries machine needs to use type_init(), call
type_register_static(), and the TypeInfo needs to specify as .class_data
the QEMUMachine and a .class_init function that assigns that QEMUMachine
pointer to mc->qemu_machine as done in machine.c.

Regards,
Andreas

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

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Alexey Kardashevskiy]

On 03/13/2014 10:38 AM, Andreas Färber wrote:
> Am 13.03.2014 00:02, schrieb Alexey Kardashevskiy:
>> On 03/13/2014 05:07 AM, Andreas Färber wrote:
>>> Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
>>>> QEMU supports firmware names for all devices in the QEMU tree but
>>>> some architectures expect some parts of firmware path names in different
>>>> format.
>>>>
>>>> This introduces a firmware-pathname-change interface definition.
>>>> If some machines needs to redefine the firmware path format, it has
>>>> to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
>>>> the device on the QOM tree (typically /machine).
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>
>>> I do not see a reply to my question on v4 and didn't catch bonzini on
>>> IRC - guessing the two lines should be swapped since both v4 and v5 were
>>> submitted by Alexey?
>>
>>
>> I am actually waiting till machine QOM'fication to finish, then I'll repost
>> this patchset. Something changed?
> 
> Yes, machine QOM'ification is queued on qom-next and the pull request
> containing it is facing some issues still. But you can already rebase
> onto git://github.com/afaerber/qemu-cpu.git qom-next branch.


gosh :( so many trees. What tree/branch should I base my
"client-architecture-support" which needs new CPU suboptions support?


> In short, the pseries machine needs to use type_init(), call
> type_register_static(), and the TypeInfo needs to specify as .class_data
> the QEMUMachine and a .class_init function that assigns that QEMUMachine
> pointer to mc->qemu_machine as done in machine.c.




-- 
Alexey

Re: [Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Alexey Kardashevskiy]

On 02/21/2014 01:05 AM, Paolo Bonzini wrote:
> Il 20/02/2014 15:03, Alexey Kardashevskiy ha scritto:
>> On 02/21/2014 12:55 AM, Paolo Bonzini wrote:
>>> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
>>>> As suffixes do not make sense for sPAPR's device tree and
>>>> there is no way to filter them out on the BusState::get_fw_dev_path
>>>> level, let's add an ability for the external caller to specify
>>>> whether to apply suffixes or not.
>>>>
>>>> We could handle suffixes in SLOF (ignore for now) but this would require
>>>> serious rework in the node opening code in SLOF which has no obvious
>>>> benefit for the currently emulated sPAPR machine.
>>>
>>> For the record, the commit message is not entirely correct in presenting
>>> the situation.  QEMU *does not care in any way* of benefits for the
>>> currently emulated sPAPR machine.  The benefit would be to QEMU in having
>>> simpler code.
>>>
>>> You just got a wildcard because Forth is scary. :)
>>
>> I know :) Should I remove that part and replace it with the "scary" one?
> 
> No, unless you have to respin for other reasons (I hope not).

I am about to respin the series against the latest QOM stuff and I am about
to change commit message in the "The benefit would be to QEMU in having
simpler code" part - what part of QEMU gets simpler? I am avoiding fixing
SLOF and I am fixing QEMU so QEMU gets (liiiiittle) bit more complicated
but not simpler :) What do I miss?


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 2/6] qdev: introduce FWPathProvider interface

[Alexey Kardashevskiy]

On 03/13/2014 05:07 AM, Andreas Färber wrote:
> Am 20.02.2014 14:50, schrieb Alexey Kardashevskiy:
>> QEMU supports firmware names for all devices in the QEMU tree but
>> some architectures expect some parts of firmware path names in different
>> format.
>>
>> This introduces a firmware-pathname-change interface definition.
>> If some machines needs to redefine the firmware path format, it has
>> to add the TYPE_FW_PATH_PROVIDER interface to an object that is above
>> the device on the QOM tree (typically /machine).
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> I do not see a reply to my question on v4 and didn't catch bonzini on
> IRC - guessing the two lines should be swapped since both v4 and v5 were
> submitted by Alexey?

I'll switch.


> 
>> ---
>> Changes:
>> v5:
>> * fixed code design
>> * added license headers
>>
>> v4:
>> * added fw-path-provider.o into tests/Makefile
>> * fixed 80chars warning from checkpatch.pl
>> ---
>>  hw/core/Makefile.objs         |  1 +
>>  hw/core/fw-path-provider.c    | 51 +++++++++++++++++++++++++++++++++++++++++++
>>  hw/core/qdev.c                | 18 ++++++++++++++-
>>  include/hw/fw-path-provider.h | 49 +++++++++++++++++++++++++++++++++++++++++
>>  tests/Makefile                |  1 +
>>  5 files changed, 119 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/core/fw-path-provider.c
>>  create mode 100644 include/hw/fw-path-provider.h
>>
>> diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
>> index 9e324be..9f75ea3 100644
>> --- a/hw/core/Makefile.objs
>> +++ b/hw/core/Makefile.objs
>> @@ -1,5 +1,6 @@
>>  # core qdev-related obj files, also used by *-user:
>>  common-obj-y += qdev.o qdev-properties.o
>> +common-obj-y += fw-path-provider.o
>>  # irq.o needed for qdev GPIO handling:
>>  common-obj-y += irq.o
>>  common-obj-y += hotplug.o
>> diff --git a/hw/core/fw-path-provider.c b/hw/core/fw-path-provider.c
>> new file mode 100644
>> index 0000000..b117157
>> --- /dev/null
>> +++ b/hw/core/fw-path-provider.c
>> @@ -0,0 +1,51 @@
>> +/*
>> + *  Firmware patch provider class and helpers.
>> + *
>> + *  This program 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; under version 2 of the License.
>> + *
>> + *  This program is distributed in the hope that it will be useful,
>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *  GNU General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License
>> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include "hw/fw-path-provider.h"
>> +
>> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
>> +                                    DeviceState *dev)
>> +{
>> +    FWPathProviderClass *k = FW_PATH_PROVIDER_GET_CLASS(p);
>> +
>> +    return k->get_dev_path(p, bus, dev);
>> +}
>> +
>> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
>> +                                        DeviceState *dev)
>> +{
>> +    FWPathProvider *p = (FWPathProvider *)
>> +        object_dynamic_cast(o, TYPE_FW_PATH_PROVIDER);
>> +
>> +    if (p) {
>> +        return fw_path_provider_get_dev_path(p, bus, dev);
>> +    }
>> +
>> +    return NULL;
>> +}
>> +
>> +static const TypeInfo fw_path_provider_info = {
>> +    .name          = TYPE_FW_PATH_PROVIDER,
>> +    .parent        = TYPE_INTERFACE,
>> +    .class_size    = sizeof(FWPathProviderClass),
>> +};
>> +
>> +static void fw_path_provider_register_types(void)
>> +{
>> +    type_register_static(&fw_path_provider_info);
>> +}
>> +
>> +type_init(fw_path_provider_register_types)
>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>> index ae30163..dd993b5 100644
>> --- a/hw/core/qdev.c
>> +++ b/hw/core/qdev.c
>> @@ -26,6 +26,7 @@
>>     this API directly.  */
>>  
>>  #include "hw/qdev.h"
>> +#include "hw/fw-path-provider.h"
>>  #include "sysemu/sysemu.h"
>>  #include "qapi/error.h"
>>  #include "qapi/qmp/qerror.h"
>> @@ -529,6 +530,18 @@ static char *bus_get_fw_dev_path(BusState *bus, DeviceState *dev)
>>      return NULL;
>>  }
>>  
>> +static char *qdev_get_fw_dev_path_from_handler(BusState *bus, DeviceState *dev)
>> +{
>> +    Object *obj = OBJECT(dev);
>> +    char *d = NULL;
>> +
>> +    while (!d && obj->parent) {
>> +        obj = obj->parent;
>> +        d = fw_path_provider_try_get_dev_path(obj, bus, dev);
>> +    }
>> +    return d;
>> +}
>> +
>>  static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>>  {
>>      int l = 0;
>> @@ -536,7 +549,10 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>>      if (dev && dev->parent_bus) {
>>          char *d;
>>          l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
>> -        d = bus_get_fw_dev_path(dev->parent_bus, dev);
>> +        d = qdev_get_fw_dev_path_from_handler(dev->parent_bus, dev);
>> +        if (!d) {
>> +            d = bus_get_fw_dev_path(dev->parent_bus, dev);
>> +        }
>>          if (d) {
>>              l += snprintf(p + l, size - l, "%s", d);
>>              g_free(d);
>> diff --git a/include/hw/fw-path-provider.h b/include/hw/fw-path-provider.h
>> new file mode 100644
>> index 0000000..8889d8b
>> --- /dev/null
>> +++ b/include/hw/fw-path-provider.h
>> @@ -0,0 +1,49 @@
>> +/*
>> + *  Firmware patch provider class and helpers definitions.
>> + *
>> + *  This program 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; under version 2 of the License.
>> + *
>> + *  This program is distributed in the hope that it will be useful,
>> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *  GNU General Public License for more details.
>> + *
>> + *  You should have received a copy of the GNU General Public License
>> + *  along with this program; if not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef FW_PATH_PROVIDER_H
>> +#define FW_PATH_PROVIDER_H 1
>> +
>> +#include "qemu-common.h"
>> +#include "qom/object.h"
>> +
>> +#define TYPE_FW_PATH_PROVIDER "fw-path-provider"
>> +
>> +#define FW_PATH_PROVIDER_CLASS(klass) \
>> +     OBJECT_CLASS_CHECK(FWPathProviderClass, (klass), TYPE_FW_PATH_PROVIDER)
>> +#define FW_PATH_PROVIDER_GET_CLASS(obj) \
>> +    OBJECT_GET_CLASS(FWPathProviderClass, (obj), TYPE_FW_PATH_PROVIDER)
>> +#define FW_PATH_PROVIDER(obj) \
>> +     INTERFACE_CHECK(FWPathProvider, (obj), TYPE_FW_PATH_PROVIDER)
>> +
>> +typedef struct FWPathProvider {
>> +    Object parent_obj;
>> +} FWPathProvider;
> 
> Unused?


Not today, this is stub. Remove?


>> +
>> +typedef void (*StreamCanPushNotifyFn)(void *opaque);
> 
> Unused?

I'll remove, looks like cut-n-paste error.


> Hoping we can consider this a bugfix and get done during freeze.


Oops. Did it manage to make it to any branch already? Which one?



> Andreas
> 
>> +
>> +typedef struct FWPathProviderClass {
>> +    InterfaceClass parent_class;
>> +
>> +    char *(*get_dev_path)(FWPathProvider *p, BusState *bus, DeviceState *dev);
>> +} FWPathProviderClass;
>> +
>> +char *fw_path_provider_get_dev_path(FWPathProvider *p, BusState *bus,
>> +                                    DeviceState *dev);
>> +char *fw_path_provider_try_get_dev_path(Object *o, BusState *bus,
>> +                                        DeviceState *dev);
>> +
>> +#endif /* FW_PATH_PROVIDER_H */
>> diff --git a/tests/Makefile b/tests/Makefile
>> index 9a7d2f1..0692b11 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -165,6 +165,7 @@ tests/test-int128$(EXESUF): tests/test-int128.o
>>  tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \
>>  	hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\
>>  	hw/core/irq.o \
>> +	hw/core/fw-path-provider.o \
>>  	$(qom-core-obj) \
>>  	$(test-qapi-obj-y) \
>>  	libqemuutil.a libqemustub.a
>>
> 
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v5 1/6] boot: extend get_boot_devices_list() to ignore suffixes

[Paolo Bonzini]

Il 13/03/2014 04:32, Alexey Kardashevskiy ha scritto:
> I am about to respin the series against the latest QOM stuff and I am about
> to change commit message in the "The benefit would be to QEMU in having
> simpler code" part - what part of QEMU gets simpler? I am avoiding fixing
> SLOF and I am fixing QEMU so QEMU gets (liiiiittle) bit more complicated
> but not simpler

The benefit would be to QEMU in having consistent naming of devices 
across all architectures.

Or just ignore me.

Paolo