aboutsummaryrefslogtreecommitdiff
path: root/hw/core/sysbus.c
AgeCommit message (Collapse)Author
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-05-29sysbus: add a sysbus_mmio_unmap() helperCédric Le Goater
This will be used to remove the MMIO regions of the POWER9 XIVE interrupt controller when the sPAPR machine is reseted. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-9-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-11sysbus: Fix latent bug with onboard devicesMarkus Armbruster
The first call of sysbus_get_default() creates the main system bus and stores it in QOM as "/machine/unattached/sysbus". This must not happen before main() creates "/machine", or else container_get() would "helpfully" create it as "container" object, and the real creation of "/machine" would later abort with "attempt to add duplicate property 'machine' to object (type 'container')". Has been that way ever since we wired up busses in QOM (commit f968fc6892d, v1.2.0). I believe the bug is latent. I got it to bite by trying to qdev_create() a sysbus device from a machine's .instance_init() method. The fix is obvious: store the main system bus in QOM right after creating "/machine". Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190308131445.17502-5-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2018-12-13core/sysbus: remove the SysBusDeviceClass::init pathMao Zhongyi
Currently, all sysbus devices have been converted to realize(), so remove this path. Cc: ehabkost@redhat.com Cc: thuth@redhat.com Cc: pbonzini@redhat.com Cc: armbru@redhat.com Cc: peter.maydell@linaro.org Cc: richard.henderson@linaro.org Cc: alistair.francis@wdc.com Signed-off-by: Mao Zhongyi <maozhongyi@cmss.chinamobile.com> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Message-id: 20181130093852.20739-22-maozhongyi@cmss.chinamobile.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-08-16sysbus: always allow explicit_ofw_unit_address() to override address generationMark Cave-Ayland
Some SysBusDevices either use sysbus_init_mmio() without sysbus_mmio_map() or the first MMIO memory region doesn't represent the bus address, causing a firmware device path with an invalid address to be generated. SysBusDeviceClass does provide a virtual explicit_ofw_unit_address() method that can be used to override this process, but it was originally intended only as as a fallback option meaning that any existing MMIO memory regions still take priority whilst determining the firmware device address. There is currently only one user of explicit_ofw_unit_address() and that is the PCI expander bridge (PXB) device which has no MMIO/PIO resources defined. This enables us to allow explicit_ofw_unit_address() to take priority without affecting backwards compatibility, allowing the address to be customised as required. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20180805112850.26063-2-mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-07-17hw/core/sysbus: Add a function for creating and attaching an objectThomas Huth
A lot of functions are initializing an object and attach it immediately afterwards to the system bus. Provide a common function for this, which also uses object_initialize_child() to make sure that the reference counter is correctly initialized to 1 afterwards. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1531745974-17187-3-git-send-email-thuth@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-01qdev: Simplify the SysBusDeviceClass::init pathPhilippe Mathieu-Daudé
Instead of using SysBusDeviceClass::realize -> DeviceClass::realize -> DeviceClass::init -> sysbus_device_init -> SysBusDeviceClass::init Simplify the path by directly calling SysBusDeviceClass::init in SysBusDeviceClass::realize: SysBusDeviceClass::realize -> SysBusDeviceClass::init Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180419212727.26095-4-f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Removal of DeviceClass::init() moved into next patch, sysbus_realize() tweaked for clarity] Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180528144509.15812-4-armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-05-17sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICEEduardo Habkost
commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 unset cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all sysbus devices appear on "-device help" and lack the "no-user" flag in "info qdm". To fix this, we can set user_creatable=false by default on TYPE_SYS_BUS_DEVICE, but this requires setting user_creatable=true explicitly on the sysbus devices that actually work with -device. Fortunately today we have just a few has_dynamic_sysbus=1 machines: virt, pc-q35-*, ppce500, and spapr. virt, ppce500, and spapr have extra checks to ensure just a few device types can be instantiated: * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE. * ppce500 supports only TYPE_ETSEC_COMMON. * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE. This patch sets user_creatable=true explicitly on those 4 device classes. Now, the more complex cases: pc-q35-*: q35 has no sysbus device whitelist yet (which is a separate bug). We are in the process of fixing it and building a sysbus whitelist on q35, but in the meantime we can fix the "-device help" and "info qdm" bugs mentioned above. Also, despite not being strictly necessary for fixing the q35 bug, reducing the list of user_creatable=true devices will help us be more confident when building the q35 whitelist. xen: We also have a hack at xen_set_dynamic_sysbus(), that sets has_dynamic_sysbus=true at runtime when using the Xen accelerator. This hack is only used to allow xen-backend devices to be dynamically plugged/unplugged. This means today we can use -device with the following 22 device types, that are the ones compiled into the qemu-system-x86_64 and qemu-system-i386 binaries: * allwinner-ahci * amd-iommu * cfi.pflash01 * esp * fw_cfg_io * fw_cfg_mem * generic-sdhci * hpet * intel-iommu * ioapic * isabus-bridge * kvmclock * kvm-ioapic * kvmvapic * SUNW,fdtwo * sysbus-ahci * sysbus-fdc * sysbus-ohci * unimplemented-device * virtio-mmio * xen-backend * xen-sysdev This patch adds user_creatable=true explicitly to those devices, temporarily, just to keep 100% compatibility with existing behavior of q35. Subsequent patches will remove user_creatable=true from the devices that are really not meant to user-creatable on any machine, and remove the FIXME comment from the ones that are really supposed to be user-creatable. This is being done in separate patches because we still don't have an obvious list of devices that will be whitelisted by q35, and I would like to get each device reviewed individually. Cc: Alexander Graf <agraf@suse.de> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Cc: Prasad J Pandit <pjp@fedoraproject.org> Cc: qemu-arm@nongnu.org Cc: qemu-block@nongnu.org Cc: qemu-ppc@nongnu.org Cc: Richard Henderson <rth@twiddle.net> Cc: Rob Herring <robh@kernel.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: sstabellini@kernel.org Cc: Thomas Huth <thuth@redhat.com> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-3-ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [ehabkost: Small changes at sysbus_device_class_init() comments] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-05-19hw: remove pio_addr_tPaolo Bonzini
pio_addr_t is almost unused, because these days I/O ports are simply accessed through the address space. cpu_{in,out}[bwl] themselves are almost unused; monitor.c and xen-hvm.c could use address_space_read/write directly, since they have an integer size at hand. This leaves qtest as the only user of those functions. On the other hand even portio_* functions use this type; the only interesting use of pio_addr_t thus is include/hw/sysbus.h. I guess I could move it there, but I don't see much benefit in that either. Using uint32_t is enough and avoids the need to include ioport.h everywhere. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-29hw/core: Clean up includesPeter Maydell
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-37-git-send-email-peter.maydell@linaro.org
2015-07-06sysbus: add irq_routing_notifierEric Auger
Add a new connect_irq_notifier notifier in the SysBusDeviceClass. This notifier, if populated, is called after sysbus_connect_irq. This mechanism is used to setup VFIO signaling once VFIO platform devices get attached to their platform bus, on a machine init done notifier. Signed-off-by: Eric Auger <eric.auger@linaro.org> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Tested-by: Vikram Sethi <vikrams@codeaurora.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2015-06-23hw/core: explicit OFW unit address callback for SysBusDeviceClassLaszlo Ersek
The sysbus_get_fw_dev_path() function formats OpenFirmware device path nodes ("driver-name@unit-address") for sysbus devices. The first choice for "unit-address" is the base address of the device's first MMIO region. The second choice is its first IO port. However, if two sysbus devices with the same "driver-name" lack both MMIO and PIO resources, then there is no good way to distinguish them based on their OFW nodes, because in this case unit-address is omitted completely for both devices. An example is TYPE_PXB_HOST ("pxb-host"). For the sake of such devices, introduce the explicit_ofw_unit_address() "virtual member function". With this function, each sysbus device in the same SysBusDeviceClass can state its own address. Cc: Markus Armbruster <armbru@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-06-19hw/core: rebase sysbus_get_fw_dev_path() to g_strdup_printf()Laszlo Ersek
This is done mainly for improving readability, and in preparation for the next patch, but Markus pointed out another bonus for the string being returned: "No arbitrary length limit. Before the patch, it's 39 characters, and the code breaks catastrophically when qdev_fw_name() is longer: the second snprintf() is called with its first argument pointing beyond path[], and its second argument underflowing to a huge size." Cc: qemu-stable@nongnu.org Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-03-10sysbus: fix memory leakGonglei
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2014-11-04sysbus: Expose MMIO enumeration helperAlexander Graf
Sysbus devices have a range of MMIO regions they expose. The exact number of regions is device specific and internal information to the device model. Expose whether a region exists via a public interface. That way our platform bus enumeration code can dynamically determine how many regions exist. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-04sysbus: Expose IRQ enumeration helpersAlexander Graf
Sysbus devices can get their IRQ lines connected to other devices. It is possible to figure out which IRQ line a connection is on and whether a sysbus device even provides an IRQ connector at a specific offset. This patch exposes helpers to make this information publicly accessible. We will need it for the platform bus dynamic sysbus enumeration. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-04sysbus: Make devices spawnable via -deviceAlexander Graf
Now that we can properly map sysbus devices that haven't been connected to something forcefully by C code, we can allow the -device command line option to spawn them. For machines that don't implement dynamic sysbus assignment in their board files we add a new bool "has_dynamic_sysbus" to the machine class. When that property is false (default), we bail out when we see dynamically spawned sysbus devices, like we did before. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-04sysbus: Add dynamic sysbus device searchAlexander Graf
Sysbus devices can be spawned by C code or dynamically via the command line. In the latter case, we need to be able to find the dynamically created devices to do things with them. This patch adds a search helper that makes it easy to look for dynamically spawned sysbus devices. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-10-23sysbus: Use TYPE_DEVICE GPIO functionalityPeter Crosthwaite
Re-implement the Sysbus GPIOs to use the existing TYPE_DEVICE GPIO named framework. A constant string name is chosen to avoid conflicts with existing unnamed GPIOs. This unifies GPIOs are IRQs for sysbus devices and allows removal of all Sysbus state for GPIOs. Any existing and future-added functionality for GPIOs is now also available for sysbus IRQs. Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-08-17sysbus: remove unused function sysbus_del_ioPaolo Bonzini
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-12-23sysbus: Set cannot_instantiate_with_device_add_yetMarkus Armbruster
device_add plugs devices into suitable bus. For "real" buses, that actually connects the device. For sysbus, the connections need to be made separately, and device_add can't do that. The device would be left unconnected, and could not possibly work. Quite a few, but not all sysbus devices already set cannot_instantiate_with_device_add_yet in their class init function. Set it in their abstract base's class init function sysbus_device_class_init(), and remove the now redundant assignments from device class init functions. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-10-14memory: Change MemoryRegion priorities from unsigned to signedMarcel Apfelbaum
When memory regions overlap, priority can be used to specify which of them takes priority. By making the priority values signed rather than unsigned, we make it more convenient to implement a situation where one "background" region should appear only where no other region exists: rather than having to explicitly specify a high priority for all the other regions, we can let them take the default (zero) priority and specify a negative priority for the background region. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-30qdev: Pass size to qbus_create_inplace()Andreas Färber
To be passed to object_initialize(). Since commit 39355c3826f5d9a2eb1ce3dc9b4cdd68893769d6 the argument is void*, so drop some superfluous (BusState *) casts or direct parent field usages. Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-04-08hw: move target-independent files to subdirectoriesPaolo Bonzini
This patch tackles all files that are compiled once, moving them to subdirectories of hw/. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>