qemu/hw/core/qdev.c

919 lines
26 KiB
C
Raw Normal View History

/*
* Dynamic device configuration and creation.
*
* Copyright (c) 2009 CodeSourcery
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library 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
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
*/
/* The theory here is that it should be possible to create a machine without
knowledge of specific devices. Historically board init routines have
passed a bunch of arguments to each device, requiring the board know
exactly which device it is dealing with. This file provides an abstract
API for device configuration and initialization. Devices will generally
inherit from a particular bus (e.g. PCI or I2C) rather than
this API directly. */
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qapi/qapi-events-qdev.h"
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qerror.h"
#include "qapi/visitor.h"
#include "qemu/error-report.h"
#include "qemu/option.h"
#include "hw/irq.h"
#include "hw/qdev-properties.h"
#include "hw/boards.h"
#include "hw/sysbus.h"
#include "hw/qdev-clock.h"
#include "migration/vmstate.h"
#include "trace.h"
static bool qdev_hot_added = false;
bool qdev_hot_removed = false;
const VMStateDescription *qdev_get_vmsd(DeviceState *dev)
{
DeviceClass *dc = DEVICE_GET_CLASS(dev);
return dc->vmsd;
}
static void bus_free_bus_child(BusChild *kid)
{
object_unref(OBJECT(kid->child));
g_free(kid);
}
static void bus_remove_child(BusState *bus, DeviceState *child)
{
BusChild *kid;
QTAILQ_FOREACH(kid, &bus->children, sibling) {
if (kid->child == child) {
char name[32];
snprintf(name, sizeof(name), "child[%d]", kid->index);
QTAILQ_REMOVE_RCU(&bus->children, kid, sibling);
qdev/core: fix qbus_is_full() The qbus_is_full(BusState *bus) function (qdev_monitor.c) compares the max_index value of the BusState structure with the max_dev value of the BusClass structure to determine whether the maximum number of children has been reached for the bus. The problem is, the max_index field of the BusState structure does not necessarily reflect the number of devices that have been plugged into the bus. Whenever a child device is plugged into the bus, the bus's max_index value is assigned to the child device and then incremented. If the child is subsequently unplugged, the value of the max_index does not change and no longer reflects the number of children. When the bus's max_index value reaches the maximum number of devices allowed for the bus (i.e., the max_dev field in the BusClass structure), attempts to plug another device will be rejected claiming that the bus is full -- even if the bus is actually empty. To resolve the problem, a new 'num_children' field is being added to the BusState structure to keep track of the number of children plugged into the bus. It will be incremented when a child is plugged, and decremented when a child is unplugged. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel<pmorel@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <1545062250-7573-1-git-send-email-akrowiak@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-17 18:57:30 +03:00
bus->num_children--;
/* This gives back ownership of kid->child back to us. */
object_property_del(OBJECT(bus), name);
/* free the bus kid, when it is safe to do so*/
call_rcu(kid, bus_free_bus_child, rcu);
break;
}
}
}
static void bus_add_child(BusState *bus, DeviceState *child)
{
char name[32];
BusChild *kid = g_malloc0(sizeof(*kid));
qdev/core: fix qbus_is_full() The qbus_is_full(BusState *bus) function (qdev_monitor.c) compares the max_index value of the BusState structure with the max_dev value of the BusClass structure to determine whether the maximum number of children has been reached for the bus. The problem is, the max_index field of the BusState structure does not necessarily reflect the number of devices that have been plugged into the bus. Whenever a child device is plugged into the bus, the bus's max_index value is assigned to the child device and then incremented. If the child is subsequently unplugged, the value of the max_index does not change and no longer reflects the number of children. When the bus's max_index value reaches the maximum number of devices allowed for the bus (i.e., the max_dev field in the BusClass structure), attempts to plug another device will be rejected claiming that the bus is full -- even if the bus is actually empty. To resolve the problem, a new 'num_children' field is being added to the BusState structure to keep track of the number of children plugged into the bus. It will be incremented when a child is plugged, and decremented when a child is unplugged. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Pierre Morel<pmorel@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <1545062250-7573-1-git-send-email-akrowiak@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-17 18:57:30 +03:00
bus->num_children++;
kid->index = bus->max_index++;
kid->child = child;
object_ref(OBJECT(kid->child));
QTAILQ_INSERT_HEAD_RCU(&bus->children, kid, sibling);
/* This transfers ownership of kid->child to the property. */
snprintf(name, sizeof(name), "child[%d]", kid->index);
object_property_add_link(OBJECT(bus), name,
object_get_typename(OBJECT(child)),
(Object **)&kid->child,
NULL, /* read-only property */
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
0);
}
static bool bus_check_address(BusState *bus, DeviceState *child, Error **errp)
{
BusClass *bc = BUS_GET_CLASS(bus);
return !bc->check_address || bc->check_address(bus, child, errp);
}
bool qdev_set_parent_bus(DeviceState *dev, BusState *bus, Error **errp)
{
hw/core/qdev: handle parent bus change regarding resettable In qdev_set_parent_bus(), when changing the parent bus of a realized device, if the source and destination buses are not in the same reset state, some adaptations are required. This patch adds needed call to resettable_change_parent() to make sure a device reset state stays coherent with its parent bus. The addition is a no-op if: 1. the device being parented is not realized. 2. the device is realized, but both buses are not under reset. Case 2 means that as long as qdev_set_parent_bus() is called during the machine realization procedure (which is before the machine reset so nothing is in reset), it is a no op. There are 52 call sites of qdev_set_parent_bus(). All but one fall into the no-op case: + 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/ {vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device parent bus just before realizing the same vdev(vgpu). + hw/core/qdev.c: when creating a device in qdev_try_create() + hw/core/sysbus.c: when initializing a device in the sysbus + hw/i386/amd_iommu.c: before realizing AMDVIState/pci + hw/isa/piix4.c: before realizing PIIX4State/rtc + hw/misc/auxbus.c: when creating an AUXBus + hw/misc/auxbus.c: when creating an AUXBus child + hw/misc/macio/macio.c: when initializing a MACIOState child + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda + hw/net/virtio-net.c: Used for migration when using the failover mechanism to migration a vfio-pci/net. It is a no-op because at this point the device is already on the bus. + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root + hw/pci-host/gpex.c: before realizing GPEXHost/root + hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev + hw/pci-host/q35.c: before realizing Q35PCIHost/mch + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root + hw/s390x/event-facility.c: when creating SCLPEventFacility/ TYPE_SCLP_QUIESCE + hw/s390x/event-facility.c: ditto with SCLPEventFacility/ TYPE_SCLP_CPU_HOTPLUG + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice just after realizing it. Ok because at this point the destination bus (sysbus) is not in reset; the realize step is before the machine reset. + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below. + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs line in ssi_auto_connect_slave(). Ok because this function is only used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c, hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c. + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device + qdev-monitor.c: in device hotplug creation procedure before realize Note that this commit alone will have no effect, right now there is no use of resettable API to reset anything. So a bus will never be tagged as in-reset by this same API. The one place where side-effect will occurs is in hw/sd/core.c in sdbus_reparent_card(). This function is only used in the raspi machines, including during the sysbus reset procedure. This case will be carrefully handled when doing the multiple phase reset transition. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-7-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:04 +03:00
BusState *old_parent_bus = dev->parent_bus;
DeviceClass *dc = DEVICE_GET_CLASS(dev);
assert(dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type));
if (!bus_check_address(bus, dev, errp)) {
return false;
}
hw/core/qdev: handle parent bus change regarding resettable In qdev_set_parent_bus(), when changing the parent bus of a realized device, if the source and destination buses are not in the same reset state, some adaptations are required. This patch adds needed call to resettable_change_parent() to make sure a device reset state stays coherent with its parent bus. The addition is a no-op if: 1. the device being parented is not realized. 2. the device is realized, but both buses are not under reset. Case 2 means that as long as qdev_set_parent_bus() is called during the machine realization procedure (which is before the machine reset so nothing is in reset), it is a no op. There are 52 call sites of qdev_set_parent_bus(). All but one fall into the no-op case: + 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/ {vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device parent bus just before realizing the same vdev(vgpu). + hw/core/qdev.c: when creating a device in qdev_try_create() + hw/core/sysbus.c: when initializing a device in the sysbus + hw/i386/amd_iommu.c: before realizing AMDVIState/pci + hw/isa/piix4.c: before realizing PIIX4State/rtc + hw/misc/auxbus.c: when creating an AUXBus + hw/misc/auxbus.c: when creating an AUXBus child + hw/misc/macio/macio.c: when initializing a MACIOState child + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda + hw/net/virtio-net.c: Used for migration when using the failover mechanism to migration a vfio-pci/net. It is a no-op because at this point the device is already on the bus. + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root + hw/pci-host/gpex.c: before realizing GPEXHost/root + hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev + hw/pci-host/q35.c: before realizing Q35PCIHost/mch + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root + hw/s390x/event-facility.c: when creating SCLPEventFacility/ TYPE_SCLP_QUIESCE + hw/s390x/event-facility.c: ditto with SCLPEventFacility/ TYPE_SCLP_CPU_HOTPLUG + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice just after realizing it. Ok because at this point the destination bus (sysbus) is not in reset; the realize step is before the machine reset. + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below. + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs line in ssi_auto_connect_slave(). Ok because this function is only used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c, hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c. + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device + qdev-monitor.c: in device hotplug creation procedure before realize Note that this commit alone will have no effect, right now there is no use of resettable API to reset anything. So a bus will never be tagged as in-reset by this same API. The one place where side-effect will occurs is in hw/sd/core.c in sdbus_reparent_card(). This function is only used in the raspi machines, including during the sysbus reset procedure. This case will be carrefully handled when doing the multiple phase reset transition. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-7-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:04 +03:00
if (old_parent_bus) {
trace_qdev_update_parent_bus(dev, object_get_typename(OBJECT(dev)),
hw/core/qdev: handle parent bus change regarding resettable In qdev_set_parent_bus(), when changing the parent bus of a realized device, if the source and destination buses are not in the same reset state, some adaptations are required. This patch adds needed call to resettable_change_parent() to make sure a device reset state stays coherent with its parent bus. The addition is a no-op if: 1. the device being parented is not realized. 2. the device is realized, but both buses are not under reset. Case 2 means that as long as qdev_set_parent_bus() is called during the machine realization procedure (which is before the machine reset so nothing is in reset), it is a no op. There are 52 call sites of qdev_set_parent_bus(). All but one fall into the no-op case: + 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/ {vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device parent bus just before realizing the same vdev(vgpu). + hw/core/qdev.c: when creating a device in qdev_try_create() + hw/core/sysbus.c: when initializing a device in the sysbus + hw/i386/amd_iommu.c: before realizing AMDVIState/pci + hw/isa/piix4.c: before realizing PIIX4State/rtc + hw/misc/auxbus.c: when creating an AUXBus + hw/misc/auxbus.c: when creating an AUXBus child + hw/misc/macio/macio.c: when initializing a MACIOState child + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda + hw/net/virtio-net.c: Used for migration when using the failover mechanism to migration a vfio-pci/net. It is a no-op because at this point the device is already on the bus. + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root + hw/pci-host/gpex.c: before realizing GPEXHost/root + hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev + hw/pci-host/q35.c: before realizing Q35PCIHost/mch + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root + hw/s390x/event-facility.c: when creating SCLPEventFacility/ TYPE_SCLP_QUIESCE + hw/s390x/event-facility.c: ditto with SCLPEventFacility/ TYPE_SCLP_CPU_HOTPLUG + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice just after realizing it. Ok because at this point the destination bus (sysbus) is not in reset; the realize step is before the machine reset. + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below. + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs line in ssi_auto_connect_slave(). Ok because this function is only used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c, hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c. + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device + qdev-monitor.c: in device hotplug creation procedure before realize Note that this commit alone will have no effect, right now there is no use of resettable API to reset anything. So a bus will never be tagged as in-reset by this same API. The one place where side-effect will occurs is in hw/sd/core.c in sdbus_reparent_card(). This function is only used in the raspi machines, including during the sysbus reset procedure. This case will be carrefully handled when doing the multiple phase reset transition. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-7-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:04 +03:00
old_parent_bus, object_get_typename(OBJECT(old_parent_bus)),
OBJECT(bus), object_get_typename(OBJECT(bus)));
/*
* Keep a reference to the device while it's not plugged into
* any bus, to avoid it potentially evaporating when it is
* dereffed in bus_remove_child().
hw/core/qdev: handle parent bus change regarding resettable In qdev_set_parent_bus(), when changing the parent bus of a realized device, if the source and destination buses are not in the same reset state, some adaptations are required. This patch adds needed call to resettable_change_parent() to make sure a device reset state stays coherent with its parent bus. The addition is a no-op if: 1. the device being parented is not realized. 2. the device is realized, but both buses are not under reset. Case 2 means that as long as qdev_set_parent_bus() is called during the machine realization procedure (which is before the machine reset so nothing is in reset), it is a no op. There are 52 call sites of qdev_set_parent_bus(). All but one fall into the no-op case: + 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/ {vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device parent bus just before realizing the same vdev(vgpu). + hw/core/qdev.c: when creating a device in qdev_try_create() + hw/core/sysbus.c: when initializing a device in the sysbus + hw/i386/amd_iommu.c: before realizing AMDVIState/pci + hw/isa/piix4.c: before realizing PIIX4State/rtc + hw/misc/auxbus.c: when creating an AUXBus + hw/misc/auxbus.c: when creating an AUXBus child + hw/misc/macio/macio.c: when initializing a MACIOState child + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda + hw/net/virtio-net.c: Used for migration when using the failover mechanism to migration a vfio-pci/net. It is a no-op because at this point the device is already on the bus. + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root + hw/pci-host/gpex.c: before realizing GPEXHost/root + hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev + hw/pci-host/q35.c: before realizing Q35PCIHost/mch + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root + hw/s390x/event-facility.c: when creating SCLPEventFacility/ TYPE_SCLP_QUIESCE + hw/s390x/event-facility.c: ditto with SCLPEventFacility/ TYPE_SCLP_CPU_HOTPLUG + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice just after realizing it. Ok because at this point the destination bus (sysbus) is not in reset; the realize step is before the machine reset. + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below. + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs line in ssi_auto_connect_slave(). Ok because this function is only used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c, hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c. + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device + qdev-monitor.c: in device hotplug creation procedure before realize Note that this commit alone will have no effect, right now there is no use of resettable API to reset anything. So a bus will never be tagged as in-reset by this same API. The one place where side-effect will occurs is in hw/sd/core.c in sdbus_reparent_card(). This function is only used in the raspi machines, including during the sysbus reset procedure. This case will be carrefully handled when doing the multiple phase reset transition. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-7-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:04 +03:00
* Also keep the ref of the parent bus until the end, so that
* we can safely call resettable_change_parent() below.
*/
object_ref(OBJECT(dev));
bus_remove_child(dev->parent_bus, dev);
}
dev->parent_bus = bus;
object_ref(OBJECT(bus));
bus_add_child(bus, dev);
hw/core/qdev: handle parent bus change regarding resettable In qdev_set_parent_bus(), when changing the parent bus of a realized device, if the source and destination buses are not in the same reset state, some adaptations are required. This patch adds needed call to resettable_change_parent() to make sure a device reset state stays coherent with its parent bus. The addition is a no-op if: 1. the device being parented is not realized. 2. the device is realized, but both buses are not under reset. Case 2 means that as long as qdev_set_parent_bus() is called during the machine realization procedure (which is before the machine reset so nothing is in reset), it is a no op. There are 52 call sites of qdev_set_parent_bus(). All but one fall into the no-op case: + 29 trivial calls related to virtio (in hw/{s390x,display,virtio}/ {vhost,virtio}-xxx.c) to set a vdev(or vgpu) composing device parent bus just before realizing the same vdev(vgpu). + hw/core/qdev.c: when creating a device in qdev_try_create() + hw/core/sysbus.c: when initializing a device in the sysbus + hw/i386/amd_iommu.c: before realizing AMDVIState/pci + hw/isa/piix4.c: before realizing PIIX4State/rtc + hw/misc/auxbus.c: when creating an AUXBus + hw/misc/auxbus.c: when creating an AUXBus child + hw/misc/macio/macio.c: when initializing a MACIOState child + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/pmu + hw/misc/macio/macio.c: before realizing NewWorldMacIOState/cuda + hw/net/virtio-net.c: Used for migration when using the failover mechanism to migration a vfio-pci/net. It is a no-op because at this point the device is already on the bus. + hw/pci-host/designware.c: before realizing DesignwarePCIEHost/root + hw/pci-host/gpex.c: before realizing GPEXHost/root + hw/pci-host/prep.c: when initialiazing PREPPCIState/pci_dev + hw/pci-host/q35.c: before realizing Q35PCIHost/mch + hw/pci-host/versatile.c: when initializing PCIVPBState/pci_dev + hw/pci-host/xilinx-pcie.c: before realizing XilinxPCIEHost/root + hw/s390x/event-facility.c: when creating SCLPEventFacility/ TYPE_SCLP_QUIESCE + hw/s390x/event-facility.c: ditto with SCLPEventFacility/ TYPE_SCLP_CPU_HOTPLUG + hw/s390x/sclp.c: Not trivial because it is called on a SLCPDevice just after realizing it. Ok because at this point the destination bus (sysbus) is not in reset; the realize step is before the machine reset. + hw/sd/core.c: Not OK. Used in sdbus_reparent_card(). See below. + hw/ssi/ssi.c: Used to put spi slave on spi bus and connect the cs line in ssi_auto_connect_slave(). Ok because this function is only used in realize step in hw/ssi/aspeed_smc.ci, hw/ssi/imx_spi.c, hw/ssi/mss-spi.c, hw/ssi/xilinx_spi.c and hw/ssi/xilinx_spips.c. + hw/xen/xen-legacy-backend.c: when creating a XenLegacyDevice device + qdev-monitor.c: in device hotplug creation procedure before realize Note that this commit alone will have no effect, right now there is no use of resettable API to reset anything. So a bus will never be tagged as in-reset by this same API. The one place where side-effect will occurs is in hw/sd/core.c in sdbus_reparent_card(). This function is only used in the raspi machines, including during the sysbus reset procedure. This case will be carrefully handled when doing the multiple phase reset transition. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200123132823.1117486-7-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:04 +03:00
if (dev->realized) {
resettable_change_parent(OBJECT(dev), OBJECT(bus),
OBJECT(old_parent_bus));
}
if (old_parent_bus) {
object_unref(OBJECT(old_parent_bus));
object_unref(OBJECT(dev));
}
return true;
}
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
DeviceState *qdev_new(const char *name)
{
module: add Error arguments to module_load and module_load_qom improve error handling during module load, by changing: bool module_load(const char *prefix, const char *lib_name); void module_load_qom(const char *type); to: int module_load(const char *prefix, const char *name, Error **errp); int module_load_qom(const char *type, Error **errp); where the return value is: -1 on module load error, and errp is set with the error 0 on module or one of its dependencies are not installed 1 on module load success 2 on module load success (module already loaded or built-in) module_load_qom_one has been introduced in: commit 28457744c345 ("module: qom module support"), which built on top of module_load_one, but discarded the bool return value. Restore it. Adapt all callers to emit errors, or ignore them, or fail hard, as appropriate in each context. Replace the previous emission of errors via fprintf in _some_ error conditions with Error and error_report, so as to emit to the appropriate target. A memory leak is also fixed as part of the module_load changes. audio: when attempting to load an audio module, report module load errors. Note that still for some callers, a single issue may generate multiple error reports, and this could be improved further. Regarding the audio code itself, audio_add() seems to ignore errors, and this should probably be improved. block: when attempting to load a block module, report module load errors. For the code paths that already use the Error API, take advantage of those to report module load errors into the Error parameter. For the other code paths, we currently emit the error, but this could be improved further by adding Error parameters to all possible code paths. console: when attempting to load a display module, report module load errors. qdev: when creating a new qdev Device object (DeviceState), report load errors. If a module cannot be loaded to create that device, now abort execution (if no CONFIG_MODULE) or exit (if CONFIG_MODULE). qom/object.c: when initializing a QOM object, or looking up class_by_name, report module load errors. qtest: when processing the "module_load" qtest command, report errors in the load of the module. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220929093035.4231-4-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-29 12:30:33 +03:00
ObjectClass *oc = object_class_by_name(name);
#ifdef CONFIG_MODULES
if (!oc) {
int rv = module_load_qom(name, &error_fatal);
if (rv > 0) {
oc = object_class_by_name(name);
} else {
error_report("could not find a module for type '%s'", name);
exit(1);
}
}
#endif
if (!oc) {
error_report("unknown type '%s'", name);
abort();
}
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
return DEVICE(object_new(name));
}
DeviceState *qdev_try_new(const char *name)
{
if (!module_object_class_by_name(name)) {
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
return NULL;
}
return DEVICE(object_new(name));
}
static QTAILQ_HEAD(, DeviceListener) device_listeners
= QTAILQ_HEAD_INITIALIZER(device_listeners);
enum ListenerDirection { Forward, Reverse };
#define DEVICE_LISTENER_CALL(_callback, _direction, _args...) \
do { \
DeviceListener *_listener; \
\
switch (_direction) { \
case Forward: \
QTAILQ_FOREACH(_listener, &device_listeners, link) { \
if (_listener->_callback) { \
_listener->_callback(_listener, ##_args); \
} \
} \
break; \
case Reverse: \
QTAILQ_FOREACH_REVERSE(_listener, &device_listeners, \
link) { \
if (_listener->_callback) { \
_listener->_callback(_listener, ##_args); \
} \
} \
break; \
default: \
abort(); \
} \
} while (0)
static int device_listener_add(DeviceState *dev, void *opaque)
{
DEVICE_LISTENER_CALL(realize, Forward, dev);
return 0;
}
void device_listener_register(DeviceListener *listener)
{
QTAILQ_INSERT_TAIL(&device_listeners, listener, link);
qbus_walk_children(sysbus_get_default(), NULL, NULL, device_listener_add,
NULL, NULL);
}
void device_listener_unregister(DeviceListener *listener)
{
QTAILQ_REMOVE(&device_listeners, listener, link);
}
bool qdev_should_hide_device(const QDict *opts, bool from_json, Error **errp)
2019-10-29 14:48:55 +03:00
{
ERRP_GUARD();
2019-10-29 14:48:55 +03:00
DeviceListener *listener;
QTAILQ_FOREACH(listener, &device_listeners, link) {
if (listener->hide_device) {
if (listener->hide_device(listener, opts, from_json, errp)) {
return true;
} else if (*errp) {
return false;
}
2019-10-29 14:48:55 +03:00
}
}
return false;
2019-10-29 14:48:55 +03:00
}
void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
int required_for_version)
{
assert(!dev->realized);
dev->instance_id_alias = alias_id;
dev->alias_required_for_version = required_for_version;
}
void device_cold_reset(DeviceState *dev)
{
resettable_reset(OBJECT(dev), RESET_TYPE_COLD);
}
bool device_is_in_reset(DeviceState *dev)
{
return resettable_is_in_reset(OBJECT(dev));
}
static ResettableState *device_get_reset_state(Object *obj)
{
DeviceState *dev = DEVICE(obj);
return &dev->reset;
}
static void device_reset_child_foreach(Object *obj, ResettableChildCallback cb,
void *opaque, ResetType type)
{
DeviceState *dev = DEVICE(obj);
BusState *bus;
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
cb(OBJECT(bus), opaque, type);
}
}
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
bool qdev_realize(DeviceState *dev, BusState *bus, Error **errp)
{
assert(!dev->realized && !dev->parent_bus);
if (bus) {
if (!qdev_set_parent_bus(dev, bus, errp)) {
return false;
}
} else {
assert(!DEVICE_GET_CLASS(dev)->bus_type);
}
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
return object_property_set_bool(OBJECT(dev), "realized", true, errp);
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
}
bool qdev_realize_and_unref(DeviceState *dev, BusState *bus, Error **errp)
{
bool ret;
ret = qdev_realize(dev, bus, errp);
object_unref(OBJECT(dev));
return ret;
}
void qdev_unrealize(DeviceState *dev)
{
qom: Put name parameter before value / visitor parameter The object_property_set_FOO() setters take property name and value in an unusual order: void object_property_set_FOO(Object *obj, FOO_TYPE value, const char *name, Error **errp) Having to pass value before name feels grating. Swap them. Same for object_property_set(), object_property_get(), and object_property_parse(). Convert callers with this Coccinelle script: @@ identifier fun = { object_property_get, object_property_parse, object_property_set_str, object_property_set_link, object_property_set_bool, object_property_set_int, object_property_set_uint, object_property_set, object_property_set_qobject }; expression obj, v, name, errp; @@ - fun(obj, v, name, errp) + fun(obj, name, v, errp) Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error message "no position information". Convert that one manually. Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Convert manually. Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused by RXCPU being used both as typedef and function-like macro there. Convert manually. The other files using RXCPU that way don't need conversion. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-27-armbru@redhat.com> [Straightforwad conflict with commit 2336172d9b "audio: set default value for pcspk.iobase property" resolved]
2020-07-07 19:05:54 +03:00
object_property_set_bool(OBJECT(dev), "realized", false, &error_abort);
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
}
static int qdev_assert_realized_properly_cb(Object *obj, void *opaque)
{
DeviceState *dev = DEVICE(object_dynamic_cast(obj, TYPE_DEVICE));
DeviceClass *dc;
if (dev) {
dc = DEVICE_GET_CLASS(dev);
assert(dev->realized);
assert(dev->parent_bus || !dc->bus_type);
}
return 0;
}
void qdev_assert_realized_properly(void)
{
object_child_foreach_recursive(object_get_root(),
qdev_assert_realized_properly_cb, NULL);
}
bool qdev_machine_modified(void)
{
return qdev_hot_added || qdev_hot_removed;
}
BusState *qdev_get_parent_bus(const DeviceState *dev)
{
return dev->parent_bus;
}
BusState *qdev_get_child_bus(DeviceState *dev, const char *name)
{
BusState *bus;
Object *child = object_resolve_path_component(OBJECT(dev), name);
bus = (BusState *)object_dynamic_cast(child, TYPE_BUS);
if (bus) {
return bus;
}
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
if (strcmp(name, bus->name) == 0) {
return bus;
}
}
return NULL;
}
int qdev_walk_children(DeviceState *dev,
qdev_walkerfn *pre_devfn, qbus_walkerfn *pre_busfn,
qdev_walkerfn *post_devfn, qbus_walkerfn *post_busfn,
void *opaque)
{
BusState *bus;
int err;
if (pre_devfn) {
err = pre_devfn(dev, opaque);
if (err) {
return err;
}
}
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
err = qbus_walk_children(bus, pre_devfn, pre_busfn,
post_devfn, post_busfn, opaque);
if (err < 0) {
return err;
}
}
if (post_devfn) {
err = post_devfn(dev, opaque);
if (err) {
return err;
}
}
return 0;
}
DeviceState *qdev_find_recursive(BusState *bus, const char *id)
{
BusChild *kid;
DeviceState *ret;
BusState *child;
WITH_RCU_READ_LOCK_GUARD() {
QTAILQ_FOREACH_RCU(kid, &bus->children, sibling) {
DeviceState *dev = kid->child;
if (dev->id && strcmp(dev->id, id) == 0) {
return dev;
}
QLIST_FOREACH(child, &dev->child_bus, sibling) {
ret = qdev_find_recursive(child, id);
if (ret) {
return ret;
}
}
}
}
return NULL;
}
char *qdev_get_dev_path(DeviceState *dev)
{
BusClass *bc;
if (!dev || !dev->parent_bus) {
return NULL;
}
bc = BUS_GET_CLASS(dev->parent_bus);
if (bc->get_dev_path) {
return bc->get_dev_path(dev);
}
return NULL;
}
void qdev_add_unplug_blocker(DeviceState *dev, Error *reason)
{
dev->unplug_blockers = g_slist_prepend(dev->unplug_blockers, reason);
}
void qdev_del_unplug_blocker(DeviceState *dev, Error *reason)
{
dev->unplug_blockers = g_slist_remove(dev->unplug_blockers, reason);
}
bool qdev_unplug_blocked(DeviceState *dev, Error **errp)
{
if (dev->unplug_blockers) {
error_propagate(errp, error_copy(dev->unplug_blockers->data));
return true;
}
return false;
}
static bool device_get_realized(Object *obj, Error **errp)
{
DeviceState *dev = DEVICE(obj);
return dev->realized;
}
static bool check_only_migratable(Object *obj, Error **errp)
{
DeviceClass *dc = DEVICE_GET_CLASS(obj);
if (!vmstate_check_only_migratable(dc->vmsd)) {
error_setg(errp, "Device %s is not migratable, but "
"--only-migratable was specified",
object_get_typename(obj));
return false;
}
return true;
}
static void device_set_realized(Object *obj, bool value, Error **errp)
{
DeviceState *dev = DEVICE(obj);
DeviceClass *dc = DEVICE_GET_CLASS(dev);
HotplugHandler *hotplug_ctrl;
BusState *bus;
NamedClockList *ncl;
Error *local_err = NULL;
bool unattached_parent = false;
static int unattached_count;
if (dev->hotplugged && !dc->hotpluggable) {
error_setg(errp, QERR_DEVICE_NO_HOTPLUG, object_get_typename(obj));
return;
}
if (value && !dev->realized) {
if (!check_only_migratable(obj, errp)) {
goto fail;
}
if (!obj->parent) {
gchar *name = g_strdup_printf("device[%d]", unattached_count++);
object_property_add_child(container_get(qdev_get_machine(),
"/unattached"),
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
name, obj);
unattached_parent = true;
g_free(name);
}
hotplug_ctrl = qdev_get_hotplug_handler(dev);
if (hotplug_ctrl) {
hotplug_handler_pre_plug(hotplug_ctrl, dev, &local_err);
if (local_err != NULL) {
goto fail;
}
}
if (dc->realize) {
dc->realize(dev, &local_err);
if (local_err != NULL) {
goto fail;
}
}
DEVICE_LISTENER_CALL(realize, Forward, dev);
qdev: store DeviceState's canonical path to use when unparenting device_unparent(dev, ...) is called when a device is unparented, either directly, or as a result of a parent device being finalized, and handles some final cleanup for the device. Part of this includes emiting a DEVICE_DELETED QMP event to notify management, which includes the device's path in the composition tree as provided by object_get_canonical_path(). object_get_canonical_path() assumes the device is still connected to the machine/root container, and will assert otherwise, but in some situations this isn't the case: If the parent is finalized as a result of object_unparent(), it will still be attached to the composition tree at the time any children are unparented as a result of that same call to object_unparent(). However, in some cases, object_unparent() will complete without finalizing the parent device, due to lingering references that won't be released till some time later. One such example is if the parent has MemoryRegion children (which take a ref on their parent), who in turn have AddressSpace's (which take a ref on their regions), since those AddressSpaces get cleaned up asynchronously by the RCU thread. In this case qdev:device_unparent() may be called for a child Device that no longer has a path to the root/machine container, causing object_get_canonical_path() to assert. Fix this by storing the canonical path during realize() so the information will still be available for device_unparent() in such cases. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-2-mdroth@linux.vnet.ibm.com> [Clear dev->canonical_path at the post_realize_fail label, which is cleaner. Suggested by David Gibson. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:13 +03:00
/*
* always free/re-initialize here since the value cannot be cleaned up
* in device_unrealize due to its usage later on in the unplug path
*/
g_free(dev->canonical_path);
dev->canonical_path = object_get_canonical_path(OBJECT(dev));
QLIST_FOREACH(ncl, &dev->clocks, node) {
if (ncl->alias) {
continue;
} else {
clock_setup_canonical_path(ncl->clock);
}
}
qdev: store DeviceState's canonical path to use when unparenting device_unparent(dev, ...) is called when a device is unparented, either directly, or as a result of a parent device being finalized, and handles some final cleanup for the device. Part of this includes emiting a DEVICE_DELETED QMP event to notify management, which includes the device's path in the composition tree as provided by object_get_canonical_path(). object_get_canonical_path() assumes the device is still connected to the machine/root container, and will assert otherwise, but in some situations this isn't the case: If the parent is finalized as a result of object_unparent(), it will still be attached to the composition tree at the time any children are unparented as a result of that same call to object_unparent(). However, in some cases, object_unparent() will complete without finalizing the parent device, due to lingering references that won't be released till some time later. One such example is if the parent has MemoryRegion children (which take a ref on their parent), who in turn have AddressSpace's (which take a ref on their regions), since those AddressSpaces get cleaned up asynchronously by the RCU thread. In this case qdev:device_unparent() may be called for a child Device that no longer has a path to the root/machine container, causing object_get_canonical_path() to assert. Fix this by storing the canonical path during realize() so the information will still be available for device_unparent() in such cases. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-2-mdroth@linux.vnet.ibm.com> [Clear dev->canonical_path at the post_realize_fail label, which is cleaner. Suggested by David Gibson. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:13 +03:00
if (qdev_get_vmsd(dev)) {
if (vmstate_register_with_alias_id(VMSTATE_IF(dev),
VMSTATE_INSTANCE_ID_ANY,
qdev_get_vmsd(dev), dev,
dev->instance_id_alias,
dev->alias_required_for_version,
&local_err) < 0) {
goto post_realize_fail;
}
}
/*
* Clear the reset state, in case the object was previously unrealized
* with a dirty state.
*/
resettable_state_clear(&dev->reset);
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
if (!qbus_realize(bus, errp)) {
goto child_realize_fail;
}
}
if (dev->hotplugged) {
/*
* Reset the device, as well as its subtree which, at this point,
* should be realized too.
*/
resettable_assert_reset(OBJECT(dev), RESET_TYPE_COLD);
resettable_change_parent(OBJECT(dev), OBJECT(dev->parent_bus),
NULL);
resettable_release_reset(OBJECT(dev), RESET_TYPE_COLD);
}
dev->pending_deleted_event = false;
if (hotplug_ctrl) {
hotplug_handler_plug(hotplug_ctrl, dev, &local_err);
if (local_err != NULL) {
goto child_realize_fail;
}
}
qatomic_store_release(&dev->realized, value);
} else if (!value && dev->realized) {
/*
* Change the value so that any concurrent users are aware
* that the device is going to be unrealized
*
* TODO: change .realized property to enum that states
* each phase of the device realization/unrealization
*/
qatomic_set(&dev->realized, value);
/*
* Ensure that concurrent users see this update prior to
* any other changes done by unrealize.
*/
smp_wmb();
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
qbus_unrealize(bus);
}
if (qdev_get_vmsd(dev)) {
vmstate_unregister(VMSTATE_IF(dev), qdev_get_vmsd(dev), dev);
}
if (dc->unrealize) {
qdev: Unrealize must not fail Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
2020-05-05 18:29:24 +03:00
dc->unrealize(dev);
}
dev->pending_deleted_event = true;
DEVICE_LISTENER_CALL(unrealize, Reverse, dev);
}
assert(local_err == NULL);
return;
child_realize_fail:
QLIST_FOREACH(bus, &dev->child_bus, sibling) {
qbus_unrealize(bus);
}
if (qdev_get_vmsd(dev)) {
vmstate_unregister(VMSTATE_IF(dev), qdev_get_vmsd(dev), dev);
}
post_realize_fail:
qdev: store DeviceState's canonical path to use when unparenting device_unparent(dev, ...) is called when a device is unparented, either directly, or as a result of a parent device being finalized, and handles some final cleanup for the device. Part of this includes emiting a DEVICE_DELETED QMP event to notify management, which includes the device's path in the composition tree as provided by object_get_canonical_path(). object_get_canonical_path() assumes the device is still connected to the machine/root container, and will assert otherwise, but in some situations this isn't the case: If the parent is finalized as a result of object_unparent(), it will still be attached to the composition tree at the time any children are unparented as a result of that same call to object_unparent(). However, in some cases, object_unparent() will complete without finalizing the parent device, due to lingering references that won't be released till some time later. One such example is if the parent has MemoryRegion children (which take a ref on their parent), who in turn have AddressSpace's (which take a ref on their regions), since those AddressSpaces get cleaned up asynchronously by the RCU thread. In this case qdev:device_unparent() may be called for a child Device that no longer has a path to the root/machine container, causing object_get_canonical_path() to assert. Fix this by storing the canonical path during realize() so the information will still be available for device_unparent() in such cases. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-2-mdroth@linux.vnet.ibm.com> [Clear dev->canonical_path at the post_realize_fail label, which is cleaner. Suggested by David Gibson. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:13 +03:00
g_free(dev->canonical_path);
dev->canonical_path = NULL;
if (dc->unrealize) {
qdev: Unrealize must not fail Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
2020-05-05 18:29:24 +03:00
dc->unrealize(dev);
}
fail:
error_propagate(errp, local_err);
if (unattached_parent) {
qdev: New qdev_new(), qdev_realize(), etc. We commonly plug devices into their bus right when we create them, like this: dev = qdev_create(bus, type_name); Note that @dev is a weak reference. The reference from @bus to @dev is the only strong one. We realize at some later time, either with object_property_set_bool(OBJECT(dev), true, "realized", errp); or its convenience wrapper qdev_init_nofail(dev); If @dev still has no QOM parent then, realizing makes the /machine/unattached/ orphanage its QOM parent. Note that the device returned by qdev_create() is plugged into a bus, but doesn't have a QOM parent, yet. Until it acquires one, unrealizing the bus will hang in bus_unparent(): while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) { DeviceState *dev = kid->child; object_unparent(OBJECT(dev)); } object_unparent() does nothing when its argument has no QOM parent, and the loop spins forever. Device state "no QOM parent, but plugged into bus" is dangerous. Paolo suggested to delay plugging into the bus until realize. We need to plug into the parent bus before we call the device's realize method, in case it uses the parent bus. So the dangerous state still exists, but only within realization, where we can manage it safely. This commit creates infrastructure to do this: dev = qdev_new(type_name); ... qdev_realize_and_unref(dev, bus, errp) Note that @dev becomes a strong reference here. qdev_realize_and_unref() drops it. There is also plain qdev_realize(), which doesn't drop it. The remainder of this series will convert all users to this new interface. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-5-armbru@redhat.com>
2020-06-10 08:31:53 +03:00
/*
* Beware, this doesn't just revert
* object_property_add_child(), it also runs bus_remove()!
*/
object_unparent(OBJECT(dev));
unattached_count--;
}
}
static bool device_get_hotpluggable(Object *obj, Error **errp)
{
DeviceClass *dc = DEVICE_GET_CLASS(obj);
DeviceState *dev = DEVICE(obj);
return dc->hotpluggable && (dev->parent_bus == NULL ||
qbus_is_hotpluggable(dev->parent_bus));
}
static bool device_get_hotplugged(Object *obj, Error **errp)
{
DeviceState *dev = DEVICE(obj);
return dev->hotplugged;
}
static void device_initfn(Object *obj)
{
DeviceState *dev = DEVICE(obj);
if (phase_check(PHASE_MACHINE_READY)) {
dev->hotplugged = 1;
qdev_hot_added = true;
}
dev->instance_id_alias = -1;
dev->realized = false;
dev->allow_unplug_during_migration = false;
QLIST_INIT(&dev->gpios);
QLIST_INIT(&dev->clocks);
}
static void device_post_init(Object *obj)
{
qdev: Fix latent bug with compat_props and onboard devices Compatibility properties started life as a qdev property thing: we supported them only for qdev properties, and implemented them with the machinery backing command line option -global. Recent commit fa0cb34d221 put them to use (tacitly) with memory backend objects (subtypes of TYPE_MEMORY_BACKEND). To make that possible, we first moved the work of applying them from the -global machinery into TYPE_DEVICE's .instance_post_init() method device_post_init(), in commits ea9ce8934c5 and b66bbee39f6, then made it available to TYPE_MEMORY_BACKEND's .instance_post_init() method host_memory_backend_post_init() as object_apply_compat_props(), in commit 1c3994f6d2a. Note the code smell: we now have function name starting with object_ in hw/core/qdev.c. It has to be there rather than in qom/, because it calls qdev_get_machine() to find the current accelerator's and machine's compat_props. Turns out calling qdev_get_machine() there is problematic. If we qdev_create() from a machine's .instance_init() method, we call device_post_init() and thus qdev_get_machine() before main() can create "/machine" in QOM. qdev_get_machine() tries to get it with container_get(), which "helpfully" creates it as "container" object, and returns that. object_apply_compat_props() tries to paper over the problem by doing nothing when the value of qdev_get_machine() isn't a TYPE_MACHINE. But the damage is done already: when main() later attempts to create the real "/machine", it fails with "attempt to add duplicate property 'machine' to object (type 'container')", and aborts. Since no machine .instance_init() calls qdev_create() so far, the bug is latent. But since I want to do that, I get to fix the bug first. Observe that object_apply_compat_props() doesn't actually need the MachineState, only its the compat_props member of its MachineClass and AccelClass. This permits a simple fix: register MachineClass and AccelClass compat_props with the object_apply_compat_props() machinery right after these classes get selected. This is actually similar to how things worked before commits ea9ce8934c5 and b66bbee39f6, except we now register much earlier. The old code registered them only after the machine's .instance_init() ran, which would've broken compatibility properties for any devices created there. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190308131445.17502-2-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-08 16:14:34 +03:00
/*
* Note: ordered so that the user's global properties take
* precedence.
*/
object_apply_compat_props(obj);
qdev: Don't exit when running into bad -global -global lets you set a nice booby-trap for yourself: $ qemu-system-x86_64 -nodefaults -S -display none -usb -monitor stdio -global usb-mouse.usb_version=l QEMU 2.1.94 monitor - type 'help' for more information (qemu) device_add usb-mouse Parameter 'usb_version' expects an int64 value or range $ echo $? 1 Not nice. Until commit 3196270 we even abort()ed. The same error triggers if you manage to screw up a machine type's compat_props. To demonstrate, change HW_COMPAT_2_1's entry to .driver = "usb-mouse",\ .property = "usb_version",\ .value = "1", \ Then run $ qemu-system-x86_64 -usb -M pc-i440fx-2.1 -device usb-mouse upstream-qemu: -device usb-mouse: Parameter 'usb_version' expects an int64 value or range $ echo $? 1 One of our creatively cruel error messages. Since this is actually a coding error, we *should* abort() here. Replace the error by an assertion failure in this case. But turn the fatal error into a mere warning when the faulty GlobalProperty comes from the user. Looks like this: $ qemu-system-x86_64 -nodefaults -S -display none -usb -monitor stdio -global usb-mouse.usb_version=l QEMU 2.1.94 monitor - type 'help' for more information (qemu) device_add usb-mouse Warning: global usb-mouse.usb_version=l ignored (Parameter 'usb_version' expects an int64 value or range) (qemu) This is consistent with how we handle similarly unusable -global in qdev_prop_check_globals(). You could argue that the error should make device_add fail. Would be harder, because we're running within TypeInfo's instance_post_init() method device_post_init(), which can't fail. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2015-01-20 12:04:07 +03:00
qdev_prop_set_globals(DEVICE(obj));
}
/* Unlink device from bus and free the structure. */
static void device_finalize(Object *obj)
{
NamedGPIOList *ngl, *next;
DeviceState *dev = DEVICE(obj);
g_assert(!dev->unplug_blockers);
QLIST_FOREACH_SAFE(ngl, &dev->gpios, node, next) {
QLIST_REMOVE(ngl, node);
qemu_free_irqs(ngl->in, ngl->num_in);
g_free(ngl->name);
g_free(ngl);
/* ngl->out irqs are owned by the other end and should not be freed
* here
*/
}
qdev: defer DEVICE_DEL event until instance_finalize() DEVICE_DEL is currently emitted when a Device is unparented, as opposed to when it is finalized. The main design motivation for this seems to be that after unparent()/unrealize(), the Device is no longer visible to the guest, and thus the operation is complete from the perspective of management. However, there are cases where remaining host-side cleanup is also pertinent to management. The is generally handled by treating these resources as aspects of the "backend", which can be managed via separate interfaces/events, such as blockdev_add/del, netdev_add/del, object_add/del, etc, but some devices do not have this level of compartmentalization, namely vfio-pci, and possibly to lend themselves well to it. In the case of vfio-pci, the "backend" cleanup happens as part of the finalization of the vfio-pci device itself, in particular the cleanup of the VFIO group FD. Failing to wait for this cleanup can result in tools like libvirt attempting to rebind the device to the host while it's still being used by VFIO, which can result in host crashes or other misbehavior depending on the host driver. Deferring DEVICE_DEL still affords us the ability to manage backends explicitly, while also addressing cases like vfio-pci's, so we implement that approach here. An alternative proposal involving having VFIO emit a separate event to denote completion of host-side cleanup was discussed, but the prevailing opinion seems to be that it is not worth the added complexity, and leaves the issue open for other Device implementations to solve in the future. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-4-mdroth@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:15 +03:00
qdev_finalize_clocklist(dev);
qdev: defer DEVICE_DEL event until instance_finalize() DEVICE_DEL is currently emitted when a Device is unparented, as opposed to when it is finalized. The main design motivation for this seems to be that after unparent()/unrealize(), the Device is no longer visible to the guest, and thus the operation is complete from the perspective of management. However, there are cases where remaining host-side cleanup is also pertinent to management. The is generally handled by treating these resources as aspects of the "backend", which can be managed via separate interfaces/events, such as blockdev_add/del, netdev_add/del, object_add/del, etc, but some devices do not have this level of compartmentalization, namely vfio-pci, and possibly to lend themselves well to it. In the case of vfio-pci, the "backend" cleanup happens as part of the finalization of the vfio-pci device itself, in particular the cleanup of the VFIO group FD. Failing to wait for this cleanup can result in tools like libvirt attempting to rebind the device to the host while it's still being used by VFIO, which can result in host crashes or other misbehavior depending on the host driver. Deferring DEVICE_DEL still affords us the ability to manage backends explicitly, while also addressing cases like vfio-pci's, so we implement that approach here. An alternative proposal involving having VFIO emit a separate event to denote completion of host-side cleanup was discussed, but the prevailing opinion seems to be that it is not worth the added complexity, and leaves the issue open for other Device implementations to solve in the future. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-4-mdroth@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:15 +03:00
/* Only send event if the device had been completely realized */
if (dev->pending_deleted_event) {
g_assert(dev->canonical_path);
qapi_event_send_device_deleted(dev->id, dev->canonical_path);
qdev: defer DEVICE_DEL event until instance_finalize() DEVICE_DEL is currently emitted when a Device is unparented, as opposed to when it is finalized. The main design motivation for this seems to be that after unparent()/unrealize(), the Device is no longer visible to the guest, and thus the operation is complete from the perspective of management. However, there are cases where remaining host-side cleanup is also pertinent to management. The is generally handled by treating these resources as aspects of the "backend", which can be managed via separate interfaces/events, such as blockdev_add/del, netdev_add/del, object_add/del, etc, but some devices do not have this level of compartmentalization, namely vfio-pci, and possibly to lend themselves well to it. In the case of vfio-pci, the "backend" cleanup happens as part of the finalization of the vfio-pci device itself, in particular the cleanup of the VFIO group FD. Failing to wait for this cleanup can result in tools like libvirt attempting to rebind the device to the host while it's still being used by VFIO, which can result in host crashes or other misbehavior depending on the host driver. Deferring DEVICE_DEL still affords us the ability to manage backends explicitly, while also addressing cases like vfio-pci's, so we implement that approach here. An alternative proposal involving having VFIO emit a separate event to denote completion of host-side cleanup was discussed, but the prevailing opinion seems to be that it is not worth the added complexity, and leaves the issue open for other Device implementations to solve in the future. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20171016222315.407-4-mdroth@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-10-17 01:23:15 +03:00
g_free(dev->canonical_path);
dev->canonical_path = NULL;
}
qobject_unref(dev->opts);
g_free(dev->id);
}
static void device_class_base_init(ObjectClass *class, void *data)
{
DeviceClass *klass = DEVICE_CLASS(class);
/* We explicitly look up properties in the superclasses,
* so do not propagate them to the subclasses.
*/
klass->props_ = NULL;
}
static void device_unparent(Object *obj)
{
DeviceState *dev = DEVICE(obj);
BusState *bus;
if (dev->realized) {
qdev_unrealize(dev);
}
while (dev->num_child_bus) {
bus = QLIST_FIRST(&dev->child_bus);
object_unparent(OBJECT(bus));
}
if (dev->parent_bus) {
bus_remove_child(dev->parent_bus, dev);
object_unref(OBJECT(dev->parent_bus));
dev->parent_bus = NULL;
}
}
static char *
device_vmstate_if_get_id(VMStateIf *obj)
{
DeviceState *dev = DEVICE(obj);
return qdev_get_dev_path(dev);
}
/**
* device_phases_reset:
* Transition reset method for devices to allow moving
* smoothly from legacy reset method to multi-phases
*/
static void device_phases_reset(DeviceState *dev)
{
ResettableClass *rc = RESETTABLE_GET_CLASS(dev);
if (rc->phases.enter) {
rc->phases.enter(OBJECT(dev), RESET_TYPE_COLD);
}
if (rc->phases.hold) {
rc->phases.hold(OBJECT(dev));
}
if (rc->phases.exit) {
rc->phases.exit(OBJECT(dev));
}
}
static void device_transitional_reset(Object *obj)
{
DeviceClass *dc = DEVICE_GET_CLASS(obj);
/*
* This will call either @device_phases_reset (for multi-phases transitioned
* devices) or a device's specific method for not-yet transitioned devices.
* In both case, it does not reset children.
*/
if (dc->reset) {
dc->reset(DEVICE(obj));
}
}
/**
* device_get_transitional_reset:
* check if the device's class is ready for multi-phase
*/
static ResettableTrFunction device_get_transitional_reset(Object *obj)
{
DeviceClass *dc = DEVICE_GET_CLASS(obj);
if (dc->reset != device_phases_reset) {
/*
* dc->reset has been overridden by a subclass,
* the device is not ready for multi phase yet.
*/
return device_transitional_reset;
}
return NULL;
}
static void device_class_init(ObjectClass *class, void *data)
{
DeviceClass *dc = DEVICE_CLASS(class);
VMStateIfClass *vc = VMSTATE_IF_CLASS(class);
ResettableClass *rc = RESETTABLE_CLASS(class);
class->unparent = device_unparent;
/* by default all devices were considered as hotpluggable,
* so with intent to check it in generic qdev_unplug() /
* device_set_realized() functions make every device
* hotpluggable. Devices that shouldn't be hotpluggable,
* should override it in their class_init()
*/
dc->hotpluggable = true;
qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-03 23:35:44 +03:00
dc->user_creatable = true;
vc->get_id = device_vmstate_if_get_id;
rc->get_state = device_get_reset_state;
rc->child_foreach = device_reset_child_foreach;
/*
* @device_phases_reset is put as the default reset method below, allowing
* to do the multi-phase transition from base classes to leaf classes. It
* allows a legacy-reset Device class to extend a multi-phases-reset
* Device class for the following reason:
* + If a base class B has been moved to multi-phase, then it does not
* override this default reset method and may have defined phase methods.
* + A child class C (extending class B) which uses
* device_class_set_parent_reset() (or similar means) to override the
* reset method will still work as expected. @device_phases_reset function
* will be registered as the parent reset method and effectively call
* parent reset phases.
*/
dc->reset = device_phases_reset;
rc->get_transitional_function = device_get_transitional_reset;
object_class_property_add_bool(class, "realized",
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
device_get_realized, device_set_realized);
object_class_property_add_bool(class, "hotpluggable",
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
device_get_hotpluggable, NULL);
object_class_property_add_bool(class, "hotplugged",
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
device_get_hotplugged, NULL);
object_class_property_add_link(class, "parent_bus", TYPE_BUS,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
offsetof(DeviceState, parent_bus), NULL, 0);
}
void device_class_set_parent_reset(DeviceClass *dc,
DeviceReset dev_reset,
DeviceReset *parent_reset)
{
*parent_reset = dc->reset;
dc->reset = dev_reset;
}
void device_class_set_parent_realize(DeviceClass *dc,
DeviceRealize dev_realize,
DeviceRealize *parent_realize)
{
*parent_realize = dc->realize;
dc->realize = dev_realize;
}
void device_class_set_parent_unrealize(DeviceClass *dc,
DeviceUnrealize dev_unrealize,
DeviceUnrealize *parent_unrealize)
{
*parent_unrealize = dc->unrealize;
dc->unrealize = dev_unrealize;
}
Object *qdev_get_machine(void)
{
static Object *dev;
if (dev == NULL) {
dev = container_get(object_get_root(), "/machine");
}
return dev;
}
static MachineInitPhase machine_phase;
bool phase_check(MachineInitPhase phase)
{
return machine_phase >= phase;
}
void phase_advance(MachineInitPhase phase)
{
assert(machine_phase == phase - 1);
machine_phase = phase;
}
static const TypeInfo device_type_info = {
.name = TYPE_DEVICE,
.parent = TYPE_OBJECT,
.instance_size = sizeof(DeviceState),
.instance_init = device_initfn,
.instance_post_init = device_post_init,
.instance_finalize = device_finalize,
.class_base_init = device_class_base_init,
.class_init = device_class_init,
.abstract = true,
.class_size = sizeof(DeviceClass),
.interfaces = (InterfaceInfo[]) {
{ TYPE_VMSTATE_IF },
{ TYPE_RESETTABLE_INTERFACE },
{ }
}
};
static void qdev_register_types(void)
{
type_register_static(&device_type_info);
}
type_init(qdev_register_types)