aboutsummaryrefslogtreecommitdiff
path: root/hw/s390x/virtio-ccw.c
AgeCommit message (Collapse)Author
2022-06-14virtio: stop ioeventfd on resetPaolo Bonzini
All calls to virtio_bus_reset are preceded by virtio_bus_stop_ioeventfd, move the call in virtio_bus_reset: that makes sense and clarifies that the vdc->reset function is called with ioeventfd already stopped. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-06-14s390x: simplify virtio_ccw_reset_virtioPaolo Bonzini
Call virtio_bus_reset instead of virtio_reset, so that the function need not receive the VirtIODevice. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-06virtio-ccw: do not include headers for all virtio devicesPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30qbus: Rename qbus_create_inplace() to qbus_init()Peter Maydell
Rename qbus_create_inplace() to qbus_init(); this is more in line with our usual naming convention for functions that in-place initialize objects. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20210923121153.23754-5-peter.maydell@linaro.org
2021-07-02virtio: disable ioeventfd for record/replayPavel Dovgalyuk
virtio devices support separate iothreads waiting for events from file descriptors. These are asynchronous events that can't be recorded and replayed, therefore this patch disables ioeventfd for all devices when record or replay is enabled. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Message-Id: <162125678869.1252810.4317416444097392406.stgit@pasha-ThinkPad-X280> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-06-21s390x/css: Refactor IRB constructionEric Farman
Currently, all subchannel types have "sense data" copied into the IRB.ECW space, and a couple flags enabled in the IRB.SCSW and IRB.ESW. But for passthrough (vfio-ccw) subchannels, this data isn't populated in the first place, so enabling those flags leads to unexpected behavior if the guest tries to process the sense data (zeros) in the IRB.ECW. Let's add a subchannel callback that builds these portions of the IRB, and move the existing code into a routine for those virtual subchannels. The passthrough subchannels will be able to piggy-back onto this later. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210617232537.1337506-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-20hw/s390x/ccw: Register qbus type in abstract TYPE_CCW_DEVICE parentPhilippe Mathieu-Daudé
Instead of having all TYPE_CCW_DEVICE children set the bus type to TYPE_VIRTUAL_CSS_BUS, do it once in the abstract parent. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20210424145313.3287400-1-f4bug@amsat.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-02hw: Do not include hw/sysbus.h if it is not necessaryThomas Huth
Many files include hw/sysbus.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210327082804.2259480-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-04-09s390x: css: report errors from ccw_dstream_read/writePierre Morel
ccw_dstream_read/write functions returned values are sometime not taking into account and reported back to the upper level of interpretation of CCW instructions. It follows that accessing an invalid address does not trigger a subchannel status program check to the guest as it should. Let's test the return values of ccw_dstream_write[_buf] and ccw_dstream_read[_buf] and report it to the caller. Cc: qemu-stable@nongnu.org Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <1617899529-9329-2-git-send-email-pmorel@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-03-26s390x: add have_virtio_ccwGerd Hoffmann
Introduce a symbol which can be used to prevent ccw modules being loaded into system emulators without ccw support. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Tested-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20210317095622.2839895-3-kraxel@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-04virtio-ccw: commands on revision-less devicesCornelia Huck
The virtio standard specifies that any non-transitional device must reject commands prior to revision setting (which we do). Devices that are transitional need to assume revision 0 (legacy) if the driver sends a non-revision-setting command first in order to support legacy drivers. We neglected to do the latter. Fortunately, nearly everything worked as intended anyway; the only problem was not properly rejecting revision setting after some other command had been issued. Easy to fix by setting revision to 0 if we see a non-revision command on a legacy-capable revision-less device. Found by code inspection, not observed in the wild. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20210216111830.1087847-1-cohuck@redhat.com>
2020-09-29virtio: skip legacy support check on machine types less than 5.1Stefano Garzarella
Commit 9b3a35ec82 ("virtio: verify that legacy support is not accidentally on") added a check that returns an error if legacy support is on, but the device does not support legacy. Unfortunately some devices were wrongly declared legacy capable even if they were not (e.g vhost-vsock). To avoid migration issues, we add a virtio-device property (x-disable-legacy-check) to skip the legacy error, printing a warning instead, for machine types < 5.1. Cc: qemu-stable@nongnu.org Fixes: 9b3a35ec82 ("virtio: verify that legacy support is not accidentally on") Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20200921122506.82515-2-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-23qemu/atomic.h: rename atomic_ to qatomic_Stefan Hajnoczi
clang's C11 atomic_fetch_*() functions only take a C11 atomic type pointer argument. QEMU uses direct types (int, etc) and this causes a compiler error when a QEMU code calls these functions in a source file that also included <stdatomic.h> via a system header file: $ CC=clang CXX=clang++ ./configure ... && make ../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) Avoid using atomic_*() names in QEMU's atomic.h since that namespace is used by <stdatomic.h>. Prefix QEMU's APIs with 'q' so that atomic.h and <stdatomic.h> can co-exist. I checked /usr/include on my machine and searched GitHub for existing "qatomic_" users but there seem to be none. This patch was generated using: $ git grep -h -o '\<atomic\(64\)\?_[a-z0-9_]\+' include/qemu/atomic.h | \ sort -u >/tmp/changed_identifiers $ for identifier in $(</tmp/changed_identifiers); do sed -i "s%\<$identifier\>%q$identifier%g" \ $(git grep -I -l "\<$identifier\>") done I manually fixed line-wrap issues and misaligned rST tables. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200923105646.47864-1-stefanha@redhat.com>
2020-09-02virtio: add Virtio*BusClass sizesCornelia Huck
Both VirtioPCIBusClass and VirtioCcwBusClass are typedefs of VirtioBusClass, but set .class_size in the TypeInfo anyway to be safe if that changes in the future. Reported-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20200824122051.99432-1-cohuck@redhat.com>
2020-07-22virtio: verify that legacy support is not accidentally onCornelia Huck
If a virtio device does not have legacy support, make sure that it is actually off, and bail out if not. For virtio-pci, this means that any device without legacy support that has been specified to modern-only (or that has been forced to it) will work. For virtio-ccw, this duplicates the check that is currently done prior to realization for any device that explicitly specified no support for legacy. This catches devices that have not been fenced properly. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200707105446.677966-3-cohuck@redhat.com> Cc: qemu-stable@nongnu.org Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-07-03virtio-ccw: fix virtio_set_ind_atomicHalil Pasic
The atomic_cmpxchg() loop is broken because we occasionally end up with old and _old having different values (a legit compiler can generate code that accessed *ind_addr again to pick up a value for _old instead of using the value of old that was already fetched according to the rules of the abstract machine). This means the underlying CS instruction may use a different old (_old) than the one we intended to use if atomic_cmpxchg() performed the xchg part. Let us use volatile to force the rules of the abstract machine for accesses to *ind_addr. Let us also rewrite the loop so, we that the new old is used to compute the new desired value if the xchg part is not performed. Fixes: 7e7494627f ("s390x/virtio-ccw: Adapter interrupt support.") Reported-by: Andre Wild <Andre.Wild1@ibm.com> Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200616045035.51641-2-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-05-15qdev: Unrealize must not failMarkus Armbruster
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-03-16misc: Replace zero-length arrays with flexible array member (manual)Philippe Mathieu-Daudé
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following command (then manual analysis, without modifying structures only having a single flexible array member, such QEDTable in block/qed.h): git grep -F '[0];' [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-20Let cpu_[physical]_memory() calls pass a boolean 'is_write' argumentPhilippe Mathieu-Daudé
Use an explicit boolean type. This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-27s390x: adapter routes error handlingCornelia Huck
If the kernel irqchip has been disabled, we don't want the {add,release}_adapter_routes routines to call any kvm_irqchip_* interfaces, as they may rely on an irqchip actually having been created. Just take a quick exit in that case instead. If you are trying to use irqfd without a kernel irqchip, we will fail with an error. Also initialize routes->gsi[] with -1 in the virtio-ccw handling, to make sure we don't trip over other errors, either. (Nobody else uses the gsi array in that structure.) Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds") Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200117111147.5006-1-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-08-16Clean up inclusion of sysemu/sysemu.hMarkus Armbruster
In my "build everything" tree, changing sysemu/sysemu.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Almost a third of its inclusions are actually superfluous. Delete them. Downgrade two more to qapi/qapi-types-run-state.h, and move one from char/serial.h to char/serial.c. hw/semihosting/config.c, monitor/monitor.c, qdev-monitor.c, and stubs/semihost.c define variables declared in sysemu/sysemu.h without including it. The compiler is cool with that, but include it anyway. This doesn't reduce actual use much, as it's still included into widely included headers. The next commit will tackle that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-27-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-08-16Include hw/hw.h exactly where neededMarkus Armbruster
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include migration/qemu-file-types.h a lot lessMarkus Armbruster
In my "build everything" tree, changing migration/qemu-file-types.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The culprit is again hw/hw.h, which supposedly includes it for convenience. Include migration/qemu-file-types.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-10-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
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]
2018-12-12hw/s390x/virtio-ccw.c: Don't take address of fields in packed structsPeter Maydell
Taking the address of a field in a packed struct is a bad idea, because it might not be actually aligned enough for that pointer type (and thus cause a crash on dereference on some host architectures). Newer versions of clang warn about this. Avoid the bug by not using the "modify in place" byte swapping functions. Patch produced with scripts/coccinelle/inplace-byteswaps.cocci (with a couple of long lines manually wrapped). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20181210120436.30522-1-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-blk code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_BLK has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532542110-9017-1-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-net code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_NET has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532542056-8927-1-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-input code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_INPUT has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-11-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-gpu code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_GPU has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-10-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move vhost-vsock-ccw code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VHOST_VSOCK has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-9-git-send-email-thuth@redhat.com> [CH: updated MAINTAINERS] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-crypto code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_CRYPTO has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-8-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-9p code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_9P and CONFIG_VIRTFS have been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-7-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-rng code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_RNG has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-6-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-scsi code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_SCSI has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-5-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-balloon code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_BALLOON has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-4-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x: Move virtio-ccw-serial code to a separate fileThomas Huth
The code should only be enabled if CONFIG_VIRTIO_SERIAL has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-3-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-28hw/s390x/virtio-ccw: Consolidate calls to virtio_ccw_unrealize()Thomas Huth
Currently, every virtio-ccw device explicitely sets its unrealize function to virtio_ccw_unrealize() in its class_init function. We can simplify this by using a common unrealize function, just like it is already done for the realize functions. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1532521224-27235-2-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-08-20s390x: remove 's390-squash-mcss' optionCornelia Huck
This option has been deprecated for two releases; remove it. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-07-11error: Remove NULL checks on error_propagate() callsPhilippe Mathieu-Daudé
Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/error_propagate_null.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir . --in-place Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20180705155811.20366-3-f4bug@amsat.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-18virtio-ccw: clean up notifyHalil Pasic
Coverity recently started complaining about virtio_ccw_notify(). Turns out, there is a couple of things that can be cleaned up. Let's clean! Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: CID 1390619 Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Message-Id: <20180516132757.68558-1-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-06-01hw: Do not include "sysemu/blockdev.h" if it is not necessaryPhilippe Mathieu-Daudé
Remove those unneeded includes to speed up the compilation process a little bit. Code change produced with: $ git grep '#include "sysemu/blockdev.h"' | \ cut -d: -f-1 | \ xargs egrep -L "(BlockInterfaceType|DriveInfo|drive_get|blk_legacy_dinfo|blockdev_mark_auto_del)" | \ xargs sed -i.bak '/#include "sysemu\/blockdev.h"/d' Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-15-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-06-01hw: Do not include "sysemu/block-backend.h" if it is not necessaryPhilippe Mathieu-Daudé
Remove those unneeded includes to speed up the compilation process a little bit. (Continue 7eceff5b5a1fa cleanup) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-13-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-14s390x/ccw: make sure all ccw devices are properly resetCornelia Huck
Thomas reported that the subchannel for a 3270 device that ended up in a broken state (status pending even though not enabled) did not get out of that state even after a reboot (which involves a subsytem reset). The reason for this is that the 3270 device did not define a reset handler. Let's fix this by introducing a base reset handler (set up for all ccw devices) that resets the subchannel and have virtio-ccw call its virtio-specific reset procedure in addition to that. CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-05-14virtio-ccw: common reset handlerCornelia Huck
All the different virtio ccw devices use the same reset handler, so let's move setting it into the base virtio ccw device class. CC: qemu-stable@nongnu.org Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/virtio: Convert virtio-ccw from *_exit to *_unrealizeNia Alarie
Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Message-Id: <20180307162958.11232-1-nia.alarie@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-02-09s390x/flic: cache the common flic class in a central functionDavid Hildenbrand
This avoids tons of conversions when handling interrupts. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180129125623.21729-19-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-01-22hw/s390x: Replace fprintf(stderr, "*\n" with qemu_log_mask()Alistair Francis
One fprintf(stderr, was manually converted to a qemu_log_mask(LOG_GUEST_ERROR, Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <3f49c0ff601f27534d4536c87c00d01c233e067f.1513790495.git.alistair.francis@xilinx.com> [CH: tweaked commit message] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-12-18Remove empty statementsLadi Prosek
Thanks to Laszlo Ersek for spotting the double semicolon in target/i386/kvm.c I have trivially grepped the tree for ';;' in C files. Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-12-14s390x/css: unrestrict cssidsHalil Pasic
The default css 0xfe is currently restricted to virtual subchannel devices. The hope when the decision was made was, that non-virtual subchannel devices will come around when guest can exploit multiple channel subsystems. Since the guests generally don't do, the pain of the partitioned (cssid) namespace outweighs the gain. Let us remove the corresponding restrictions (virtual devices can be put only in 0xfe and non-virtual devices in any css except the 0xfe -- while s390-squash-mcss then remaps everything to cssid 0). At the same time, change our schema for generating css bus ids to put both virtual and non-virtual devices into the default css (spilling over into other css images, if needed). The intention is to deprecate s390-squash-mcss. With this change devices without a specified devno won't end up hidden to guests not supporting multiple channel subsystems, unless this can not be avoided (default css full). Let us also advertise the changes to the management software (so it can tell are cssids unrestricted or restricted). The adverse effect of getting rid of the restriction on migration should not be too severe. Vfio-ccw devices are not live-migratable yet, and for virtual devices using the extra freedom would only make sense with the aforementioned guest support in place. The auto-generated bus ids are affected by both changes. We hope to not encounter any auto-generated bus ids in production as Libvirt is always explicit about the bus id. Since 8ed179c937 ("s390x/css: catch section mismatch on load", 2017-05-18) the worst that can happen because the same device ended up having a different bus id is a cleanly failed migration. I find it hard to reason about the impact of changed auto-generated bus ids on migration for command line users as I don't know which rules is such an user supposed to follow. Another pain-point is down- or upgrade of QEMU for command line users. The old way and the new way of doing vfio-ccw are mutually incompatible. Libvirt is only going to support the new way, so for libvirt users, the possible problems at QEMU downgrade are the following. If a domain contains virtual devices placed into a css different than 0xfe the domain will refuse to start with a QEMU not having this patch. Putting devices into a css different that 0xfe however won't make much sense in the near future (guest support). Libvirt will refuse to do vfio-ccw with a QEMU not having this patch. This is business as usual. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20171206144438.28908-2-pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-10-20virtio-ccw: Add the virtio-input devices for CCW busFarhan Ali
Wire up the virtio-input HID devices (keyboard, mouse, tablet) for the CCW bus. The virtio-input is a virtio-1 device, so disable legacy revision 0. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <6a8ea4c503ee32c2ca7fa608b5f2f547009be8ee.1507557166.git.alifm@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>