summaryrefslogtreecommitdiff
path: root/hw/virtio/virtio-bus.c
AgeCommit message (Collapse)Author
2021-09-04virtio-bus: introduce iommu_enabled()Jason Wang
This patch introduce a new method for the virtio-bus for the transport to report whether or not the IOMMU is enabled for the device. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20210804034803.1644-2-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-05-18virtio: Fail if iommu_platform is requested, but unsupportedKevin Wolf
Commit 2943b53f6 (' virtio: force VIRTIO_F_IOMMU_PLATFORM') made sure that vhost can't just reject VIRTIO_F_IOMMU_PLATFORM when it was requested. However, just adding it back to the negotiated flags isn't right either because it promises support to the guest that the device actually doesn't support. One example of a vhost-user device that doesn't have support for the flag is the vhost-user-blk export of QEMU. Instead of successfully creating a device that doesn't work, just fail to plug the device when it doesn't support the feature, but it was requested. This results in much clearer error messages. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1935019 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20210429171316.162022-6-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-11-06virtio: notify virtqueue via host notifier when availableStefan Hajnoczi
Host notifiers are used in several cases: 1. Traditional ioeventfd where virtqueue notifications are handled in the main loop thread. 2. IOThreads (aio_handle_output) where virtqueue notifications are handled in an IOThread AioContext. 3. vhost where virtqueue notifications are handled by kernel vhost or a vhost-user device backend. Most virtqueue notifications from the guest use the ioeventfd mechanism, but there are corner cases where QEMU code calls virtio_queue_notify(). This currently honors the host notifier for the IOThreads aio_handle_output case, but not for the vhost case. The result is that vhost does not receive virtqueue notifications from QEMU when virtio_queue_notify() is called. This patch extends virtio_queue_notify() to set the host notifier whenever it is enabled instead of calling the vq->(aio_)handle_output() function directly. We track the host notifier state for each virtqueue separately since some devices may use it only for certain virtqueues. This fixes the vhost case although it does add a trip through the eventfd for the traditional ioeventfd case. I don't think it's worth adding a fast path for the traditional ioeventfd case because calling virtio_queue_notify() is rare when ioeventfd is enabled. Reported-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20191105140946.165584-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
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-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-02-08virtio: remove event notifier cleanup call on de-assignGal Hammer
The virtio_bus_set_host_notifier function no longer calls event_notifier_cleanup when a event notifier is removed. The commit updates the code to match the new behavior and calls virtio_bus_cleanup_host_notifier after the notifier was de-assign and no longer in use. This change is a preparation to allow executing the virtio_bus_set_host_notifier function in a memory region transaction. Signed-off-by: Gal Hammer <ghammer@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-24Revert "virtio: postpone the execution of event_notifier_cleanup function"Michael S. Tsirkin
This reverts commit 4fe6d78b2e241f41208dfb07605aace4becfc747 as it is reported to break cleanup and migration. Cc: Gal Hammer <ghammer@redhat.com> Cc: Sitong Liu <siliu@redhat.com> Cc: Xiaoling Gao <xiagao@redhat.com> Suggested-by: Greg Kurz <groug@kaod.org> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reported-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reported-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
2018-01-18virtio: postpone the execution of event_notifier_cleanup functionGal Hammer
Use the EventNotifier's cleanup callback function to execute the event_notifier_cleanup function after kvm unregistered the eventfd. This change supports running the virtio_bus_set_host_notifier function inside a memory region transaction. Otherwise, a closed fd is sent to kvm, which results in a failure. Signed-off-by: Gal Hammer <ghammer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-03-22virtio: Fix error handling in virtio_bus_device_pluggedFam Zheng
For one thing we shouldn't continue if an error happened, for the other two steps failing can cause an abort() in error_setg because we reuse the same errp blindly. Add error handling checks to fix both issues. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-01-19virtio: force VIRTIO_F_IOMMU_PLATFORMJason Wang
We allow vhost to clear VIRITO_F_IOMMU_PLATFORM which is wrong since VIRTIO_F_IOMMU_PLATFORM is mandatory for security. Fixing this by enforce it after vdc->get_features(). Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-01-10virtio: convert to use DMA apiJason Wang
Currently, all virtio devices bypass IOMMU completely. This is because address_space_memory is assumed and used during DMA emulation. This patch converts the virtio core API to use DMA API. This idea is - introducing a new transport specific helper to query the dma address space. (only pci version is implemented). - query and use this address space during virtio device guest memory accessing when iommu platform (VIRTIO_F_IOMMU_PLATFORM) was enabled for this device. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Amit Shah <amit.shah@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-11-18virtio: introduce grab/release_ioeventfd to fix vhostPaolo Bonzini
Following the recent refactoring of virtio notifiers [1], more specifically the patch ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2] by default, core virtio code requires 'ioeventfd_started' to be set to true/false when the host notifiers are configured. When vhost is stopped and started, however, there is a stop followed by another start. Since ioeventfd_started was never set to true, the 'stop' operation triggered by virtio_bus_set_host_notifier() will not result in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves the memory regions with stale notifiers and results on the next start triggering the following assertion: kvm_mem_ioeventfd_add: error adding ioeventfd: File exists Aborted This patch reintroduces (hopefully in a cleaner way) the concept that was present with ioeventfd_disabled before the refactoring. When ioeventfd_grabbed>0, ioeventfd_started tracks whether ioeventfd should be enabled or not, but ioeventfd is actually not started at all until vhost releases the host notifiers. [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.html Reported-by: Felipe Franciosi <felipe@nutanix.com> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Reported-by: Alex Williamson <alex.williamson@redhat.com> Fixes: ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd") Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Farhan Ali <alifm@linux.vnet.ibm.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: inline set_host_notifier_internalPaolo Bonzini
This is only called from virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: inline virtio_queue_set_host_notifier_fd_handlerPaolo Bonzini
Of the three possible parameter combinations for virtio_queue_set_host_notifier_fd_handler: - assign=true/set_handler=true is only called from virtio_device_start_ioeventfd - assign=false/set_handler=false is called from set_host_notifier_internal but it only does something when reached from virtio_device_stop_ioeventfd_impl; otherwise there is no EventNotifier set on qemu_get_aio_context(). - assign=true/set_handler=false is called from set_host_notifier_internal, but it is not doing anything: with the new start_ioeventfd and stop_ioeventfd methods, there is never an EventNotifier set on qemu_get_aio_context() at this point. This is enforced by the assertion in virtio_bus_set_host_notifier. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: use virtio_bus_set_host_notifier to start/stop ioeventfdPaolo Bonzini
ioeventfd_disabled was the only reason for the default implementation of virtio_device_start_ioeventfd not to use virtio_bus_set_host_notifier. This is now fixed, and the sole entry point to set up ioeventfd can be virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: remove ioeventfd_disabled altogetherPaolo Bonzini
Now that there is not anymore a switch from the generic ioeventfd handler to the dataplane handler, virtio_bus_set_host_notifier(assign=true) is always called with !bus->ioeventfd_started, hence virtio_bus_stop_ioeventfd does nothing in this case. Move the invocation to vhost.c, which is the only place that needs it. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: remove set_handler argument from set_host_notifier_internalPaolo Bonzini
Make virtio_device_start_ioeventfd_impl use the same logic as dataplane to set up the host notifier. This removes the need for the set_handler argument in set_host_notifier_internal. This is a first step towards using virtio_bus_set_host_notifier as the sole entry point to set up ioeventfds. At least now the functions have the same interface, but they still differ in that virtio_bus_set_host_notifier sets ioeventfd_disabled. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: introduce virtio_device_ioeventfd_enabledPaolo Bonzini
This will be used to forbid iothread configuration when the proxy does not allow using ioeventfd. To simplify the implementation, change the direction of the ioeventfd_disabled callback too. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: add start_ioeventfd and stop_ioeventfd to VirtioDeviceClassPaolo Bonzini
Allow customization of the start and stop of ioeventfd. This will allow direct start of dataplane without passing through the default ioeventfd handlers, which in turn allows using the dataplane logic instead of virtio_add_queue_aio. It will also enable some code simplification, because the sole entry point to ioeventfd setup will be virtio_bus_set_host_notifier. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: move ioeventfd_started flag to VirtioBusStatePaolo Bonzini
This simplifies the code and removes the ioeventfd_started and ioeventfd_set_started callback. The only difference is in how virtio-ccw handles an error---it doesn't disable ioeventfd forever anymore. It was the only backend to do so, and if desired this behavior should be implemented in virtio-bus.c. Instead of ioeventfd_started, the ioeventfd_assign callback now determines whether the virtio bus supports host notifiers. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-10-30virtio: move ioeventfd_disabled flag to VirtioBusStatePaolo Bonzini
This simplifies the code and removes the ioeventfd_set_disabled callback. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-09-15virtio-bus: Plug devices after features are negotiatedMaxime Coquelin
Currently, devices are plugged before features are negotiated. If the backend doesn't support VIRTIO_F_VERSION_1, the transport needs to rewind some settings. This is the case for CCW, for which a post_plugged callback had been introduced, where max_rev field is just updated if VIRTIO_F_VERSION_1 is not supported by the backend. For PCI, implementing post_plugged would be much more complicated, so it needs to know whether the backend supports VIRTIO_F_VERSION_1 at plug time. Currently, nothing is done for PCI. Modern capabilities get exposed to the guest even if VIRTIO_F_VERSION_1 is not supported by the backend, which confuses the guest. This patch replaces existing post_plugged solution with an approach that fits with both transports. Features negotiation is performed before ->device_plugged() call. A pre_plugged callback is introduced so that the transports can set their supported features. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com> [ccw] Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
2016-09-09virtio: Tell the user what went wrong when event_notifier_init failedThomas Huth
event_notifier_init() can fail in real life, for example when there are not enough open file handles available (EMFILE) when using a lot of devices. So instead of leaving the average user with a cryptic error number only, print out a proper error message with strerror() instead, so that the user has a better way to figure out what is going on and that using "ulimit -n" might help here for example. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-04virtio: revert host notifiers to old semanticsCornelia Huck
The host notifier rework tried both to unify host notifiers across transports and plug a possible hole during host notifier re-assignment. Unfortunately, this meant a change in semantics that breaks vhost and iSCSI+dataplane. As the minimal fix, keep the common host notifier code but revert to the old semantics so that we have time to figure out the proper fix. Fixes: 6798e245a3 ("virtio-bus: common ioeventfd infrastructure") Reported-by: Peter Lieven <pl@kamp.de> Reported-by: Jason Wang <jasowang@redhat.com> Reported-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Tested-by: Jason Wang <jasowang@redhat.com> Tested-by: Peter Lieven <pl@kamp.de>
2016-06-24virtio-bus: common ioeventfd infrastructureCornelia Huck
Introduce a set of ioeventfd callbacks on the virtio-bus level that can be implemented by the individual transports. At the virtio-bus level, do common handling for host notifiers (which is actually most of it). Two things of note: - When setting the host notifier, we only switch from/to the generic ioeventfd handler. This fixes a latent bug where we had no ioeventfd assigned for a certain window. - We always iterate over all possible virtio queues, even though ccw (currently) has a lower limit. It does not really matter here. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-01-29virtio: 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-15-git-send-email-peter.maydell@linaro.org
2015-12-02virtio: handle non-virtio-1-capable backend for ccwCornelia Huck
If you run a qemu advertising VERSION_1 with an old kernel where vhost did not yet support VERSION_1, you'll end up with a device that is {modern pci|ccw revision 1} but does not advertise VERSION_1. This is not a sensible configuration and is rejected by the Linux guest drivers. To fix this, add a ->post_plugged() callback invoked after features have been queried that can handle the VERSION_1 bit being withdrawn and change ccw to fall back to revision 0 if VERSION_1 is gone. Note that pci is _not_ fixed; we'll need to rethink the approach for the next release but at least for pci it's not a regression. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-07-27virtio: get_features() can failJason Wang
Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2015-05-31virtio: device_plugged() can failJason Wang
This patch passes error pointer to transport specific device_plugged() callback. Through this way, device_plugged() can do some transport specific check and fail. This will be uesd by following patches that check the number of virtqueues against the transport limitation. Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-31virtio: move host_featuresCornelia Huck
Move host_features from the individual transport proxies into the virtio device. Transports may continue to add feature bits during device plugging. This should it make easier to offer different sets of host features for virtio-1/transitional support. Tested-by: Shannon Zhao <shannon.zhao@linaro.org> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-02-26virtio: cull virtio_bus_set_vdev_featuresCornelia Huck
The only user of this function was virtio-ccw, and it should use virtio_set_features() like everybody else: We need to make sure that bad features are masked out properly, which this function did not do. Reviewed-by: Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-12-10virtio-bus: avoid breaking build when open DEBUG switchGonglei
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2013-12-09virtio-bus: cleanup plug/unplug interfacePaolo Bonzini
Right now we have these pairs: - virtio_bus_plug_device/virtio_bus_destroy_device. The first takes a VirtIODevice, the second takes a VirtioBusState - device_plugged/device_unplug callbacks in the VirtioBusClass (here it's just the naming that is inconsistent) - virtio_bus_destroy_device is not called by anyone (and since it calls qdev_free, it would be called by the proxies---but then the callback is useless since the proxies can do whatever they want before calling virtio_bus_destroy_device) And there is a k->init but no k->exit, hence virtio_device_exit is overwritten by subclasses (except virtio-9p). This cleans it up by: - renaming the device_unplug callback to device_unplugged - renaming virtio_bus_plug_device to virtio_bus_device_plugged, matching the callback name - renaming virtio_bus_destroy_device to virtio_bus_device_unplugged, removing the qdev_free, making it take a VirtIODevice and calling it from virtio_device_exit - adding a k->exit callback virtio_device_exit is still overwritten, the next patches will fix that. Cc: qemu-stable@nongnu.org Acked-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-12-09virtio-bus: remove vdev fieldPaolo Bonzini
The vdev field is complicated to synchronize. Just access the BusState's list of children. Cc: qemu-stable@nongnu.org Acked-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-11-05qdev: Drop misleading qdev_free() functionStefan Hajnoczi
The qdev_free() function name is misleading since all the function does is unlink the device from its parent. The device is not necessarily freed. The device will be freed when its QObject refcount reaches zero. It is usual for the parent (bus) to hold the final reference but there are cases where something else holds a reference so "free" is a misleading name. Call object_unparent(obj) directly instead of having a qdev wrapper function. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-05-30qdev: fix get_fw_dev_path to support to add nothing to fw_dev_pathAmos Kong
Recent virtio refactoring in QEMU made virtio-bus become the parent bus of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation, typename will be added to fw_dev_path by default, the new fw_dev_path could not be identified by seabios. It causes that bootindex parameter of scsi device doesn't work. This patch implements get_fw_dev_path() in BusClass, it will be called if bus doesn't implement the method, tyename will be added to fw_dev_path. If the implemented method returns NULL, nothing will be added to fw_dev_path. It also implements virtio_bus_get_fw_dev_path() to return NULL. Then QEMU will still pass original style of fw_dev_path to seabios. Signed-off-by: Amos Kong <akong@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1369814202-10346-1-git-send-email-akong@redhat.com -- v2: only add nothing to fw_dev_path when get_fw_dev_path() is implemented and returns NULL. then it will not effect other devices don't have get_fw_dev_path() implementation. v3: implement default get_fw_dev_path() in BusClass Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-05-16virtio: add virtio_bus_get_dev_path.KONRAD Frederic
This adds virtio_bus_get_dev_path to fix migration id string which is wrong since the virtio refactoring. Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1368723967-21050-1-git-send-email-fred.konrad@greensocs.com Cc: mdroth <mdroth@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-24virtio: remove virtiobindings.KONRAD Frederic
This remove virtio-bindings, and use class instead. Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> Message-id: 1366791683-5350-6-git-send-email-fred.konrad@greensocs.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-24virtio-bus: add new functions.KONRAD Frederic
This add two functions: * virtio_bus_set_vdev_config. * virtio_bus_set_vdev_feature. Needed by virtio-ccw. Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> Message-id: 1366791683-5350-2-git-send-email-fred.konrad@greensocs.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>