aboutsummaryrefslogtreecommitdiff
path: root/tests/qemu-iotests/240.out
diff options
context:
space:
mode:
authorKevin Wolf <kwolf@redhat.com>2019-04-29 17:40:14 +0200
committerKevin Wolf <kwolf@redhat.com>2019-06-04 15:22:22 +0200
commit307a5f60ebe0506a5b90f323fdcabb4333405484 (patch)
tree832416121763177222a0ac06ecad4aeda34c6240 /tests/qemu-iotests/240.out
parentd861ab3acf8dcf817e0c2335979b258847b69564 (diff)
block: Add qdev_prop_drive_iothread property type
Some qdev block devices have support for iothreads and take care of the AioContext they are running in, but most devices don't know about any of this. For the latter category, the qdev drive property must make sure that their BlockBackend is in the main AioContext. Unfortunately, while the current code just does the same thing for devices that do support iothreads, this is not correct and it would show as soon as we actually try to keep a consistent AioContext assignment across all nodes and users of a block graph subtree: If a node is already in a non-default AioContext because of one of its users, attaching a new device should still be possible if that device can work in the same AioContext. Switching the node back to the main context first and only then into the device AioContext causes failure (because the existing user wouldn't allow the switch to the main context). So devices that support iothreads need a different kind of drive property that leaves the node in its current AioContext, but by using this type, the device promises to check later that it can work with this context. This patch adds the qdev infrastructure that allows devices to signal that they handle iothreads and qdev should leave the AioContext alone. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'tests/qemu-iotests/240.out')
0 files changed, 0 insertions, 0 deletions