aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x/css-bridge.c
AgeCommit message (Collapse)AuthorFilesLines
2017-04-21s390x: register I/O adapters per ISC during initFei Li1-0/+3
The I/O adapters should exist as soon as the bus/infrastructure exists, and not only when the guest is actually trying to do something with them. While the lazy allocation was not wrong, allocating at init time is cleaner, both for the architecture and the code. Let's adjust this by having each device type (currently for PCI and virtio-ccw) register the adapters for each ISC (as now we don't know which ISC the guest will use) as soon as it initializes. Use a two-dimensional array io_adapters[type][isc] to store adapters in ChannelSubSys, so that we can conveniently get the adapter id by the helper function css_get_adapter_id(type, isc). Signed-off-by: Fei Li <sherrylf@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-20s390x/css: provide a dev_path for css devicesCornelia Huck1-1/+25
We need to implement the get_dev_path method for the css bus, or else we might end up with two different devices having the same qdev_path. This was noticed when adding two scsi_hd controllers: The SCSIBus code will produce a non-unique dev_path for vmstate usage if the parent bus does not provide the get_dev_path method. We simply use the device's bus id, as this is unique and we won't have any deeper hierarchy from a channel subsystem perspective anyway. Note that we need to disable this for older machine versions, as this changes the migration format. Reported-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Tested-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: Unplug handler of virtual css bridgeJing Liu1-2/+37
The previous patch moved virtual css bridge and bus out from virtio-ccw, but kept the direct reference of virtio-ccw specific unplug function inside css-bridge.c. To make the virtual css bus and bridge useful for non-virtio devices, this introduces a common unplug function pointer "unplug" to call specific virtio-ccw unplug parts. Thus, the tight coupling to virtio-ccw can be removed. This unplug pointer is a member of CCWDeviceClass, which is introduced as an abstract device layer called "ccw-device". This layer is between DeviceState and specific devices which are plugged in virtual css bus, like virtio-ccw device. The specific unplug handlers should be assigned to "unplug" during initialization. Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-11s390x/css: Factor out virtual css bridge and busJing Liu1-0/+89
Currently, common base layers virtual css bridge and bus are defined in hw/s390x/virtio-ccw.c(h). In order to support multiple types of devices in the virtual channel subsystem, especially non virtio-ccw, refactoring work needs to be done. This work is just a pure code move without any functional change except dropping an empty function virtual_css_bridge_init() and virtio_ccw_busdev_unplug() changing. virtio_ccw_busdev_unplug() is specific to virtio-ccw but gets referenced from the common virtual css bridge code. To keep the functional changes to a minimum we export this function from virtio-ccw.c and continue to reference it inside virtual_css_bridge_class_init() (now living in hw/s390x/css-bridge.c). A follow-up patch will clean this up. Signed-off-by: Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>