summaryrefslogtreecommitdiffstats
path: root/block.c
Commit message (Collapse)AuthorAgeFilesLines
* block: Cancel jobs first in bdrv_close_all()Kevin Wolf2016-05-251-21/+2Star
| | | | | | | | | | | | | | | | | | So far, bdrv_close_all() first removed all root BlockDriverStates of BlockBackends and monitor owned BDSes, and then assumed that the remaining BDSes must be related to jobs and cancelled these jobs. This order doesn't work that well any more when block jobs use BlockBackends internally because then they will lose their BDS before being cancelled. This patch changes bdrv_close_all() to first cancel all jobs and then remove all root BDSes from the remaining BBs. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Propagate .drained_begin/end callbacksKevin Wolf2016-05-251-1/+19
| | | | | | | | | | | | When draining intermediate nodes (i.e. nodes that aren't the root node for at least one of their parents; with node references, the user can always configure the graph to create this situation), we need to propagate the .drained_begin/end callbacks all the way up to the root for the drain to be effective. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
* block: Fix reconfiguring graph with drained nodesKevin Wolf2016-05-251-4/+14
| | | | | | | | | | | | | | | | | When changing the BlockDriverState that a BdrvChild points to while the node is currently drained, we must call the .drained_end() parent callback. Conversely, when this means attaching a new node that is already drained, we need to call .drained_begin(). bdrv_root_attach_child() takes now an opaque parameter, which is needed because the callbacks must also be called if we're attaching a new child to the BlockBackend when the root node is already drained, and they need a way to identify the BlockBackend. Previously, child->opaque was set too late and the callbacks would still see it as NULL. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
* block: Introduce bdrv_replace_child()Kevin Wolf2016-05-251-6/+20
| | | | | | | | | | This adds a common function that is called when attaching a new child to a parent, removing a child from a parent and when reconfiguring the graph so that an existing child points to a different node now. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
* block: Drop bdrv_parent_cb_...() from bdrv_close()Max Reitz2016-05-251-2/+0Star
| | | | | | | | | | bdrv_close() now asserts that the BDS's refcount is 0, therefore it cannot have any parents and the bdrv_parent_cb_change_media() call is a no-op. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Assert !bs->refcnt in bdrv_close()Max Reitz2016-05-251-2/+1Star
| | | | | | | | | | | | | | | | The only caller of bdrv_close() left is bdrv_delete(). We may as well assert that, in a way (there are some things in bdrv_close() that make more sense under that assumption, such as the call to bdrv_release_all_dirty_bitmaps() which in turn assumes that no frozen bitmaps are attached to the BDS). In addition, being called only in bdrv_delete() means that we can drop bdrv_close()'s forward declaration at the top of block.c. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Make bdrv_open() return a BDSMax Reitz2016-05-251-94/+44Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are no callers to bdrv_open() or bdrv_open_inherit() left that pass a pointer to a non-NULL BDS pointer as the first argument of these functions, so we can finally drop that parameter and just make them return the new BDS. Generally, the following pattern is applied: bs = NULL; ret = bdrv_open(&bs, ..., &local_err); if (ret < 0) { error_propagate(errp, local_err); ... } by bs = bdrv_open(..., errp); if (!bs) { ret = -EINVAL; ... } Of course, there are only a few instances where the pattern is really pure. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Drop bdrv_new_root()Max Reitz2016-05-251-5/+0Star
| | | | | | | | | It is unused now, so we may just as well drop it. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Let bdrv_open_inherit() return the snapshotMax Reitz2016-05-251-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If bdrv_open_inherit() creates a snapshot BDS and *pbs is NULL, that snapshot BDS should be returned instead of the BDS under it. This has worked so far because (nearly) all users of BDRV_O_SNAPSHOT use blk_new_open() to create the BDS tree. bdrv_append() (which is called by bdrv_append_temp_snapshot()) redirects pointers from parents (i.e. the BB in this case) to the newly appended child (i.e. the overlay), therefore, while bdrv_open_inherit() did not return the root BDS, the BB still pointed to it. The only instance where BDRV_O_SNAPSHOT is used but blk_new_open() is not is in blockdev_init() if no BDS tree is created, and instead blk_new() is used and the flags are stored in the BB root state. However, qmp_blockdev_change_medium() filters the BDRV_O_SNAPSHOT flag before invoking bdrv_open(), so it will not have any effect. In any case, it would be nicer if bdrv_open_inherit() could just always return the root of the BDS tree that has been created. To this end, bdrv_append_temp_snapshot() now returns the snapshot BDS instead of just appending it on top of the snapshotted BDS. Also, it calls bdrv_ref() before bdrv_append() (which bdrv_open_inherit() has to undo if not returning the overlay). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Drop useless bdrv_new() callMax Reitz2016-05-251-2/+1Star
| | | | | | | | | | | | | bdrv_append_temp_snapshot() uses bdrv_new() to create an empty BDS before invoking bdrv_open() on that BDS. This is probably a relict from when it used to do some modifications on that empty BDS, but now that is unnecessary, so we can just set bs_snapshot to NULL and let bdrv_open() do the rest. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Fix bdrv_next() memory leakKevin Wolf2016-05-251-10/+8Star
| | | | | | | | | | | | | | The bdrv_next() users all leaked the BdrvNextIterator after completing the iteration. Simply changing bdrv_next() to free the iterator before returning NULL at the end of list doesn't work because some callers exit the loop before looking at all BDSes. This patch moves the BdrvNextIterator from the heap to the stack of the caller and switches to a bdrv_first()/bdrv_next() interface for initialising the iterator. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
* block: Propagate AioContext change to all childrenMax Reitz2016-05-191-10/+6Star
| | | | | | | | | | | | | Instead of propagating any change of a BDS's AioContext only to its file and backing children and letting driver-specific code do the rest, just propagate it to all and drop the thus superfluous implementations of bdrv_{at,de}tach_aio_context() in Quorum, blkverify and VMDK. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Remove BlockDriverState.blkKevin Wolf2016-05-191-9/+1Star
| | | | | | | | | | | | | This patch removes the remaining users of bs->blk, which will allow us to have multiple BBs on top of a single BDS. In the meantime, all checks that are currently in place to prevent the user from creating such setups can be switched to bdrv_has_blk() instead of accessing BDS.blk. Future patches can allow them and e.g. enable users to mirror to a block device that already has a BlockBackend on it. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Avoid bs->blk in bdrv_next()Kevin Wolf2016-05-191-28/+12Star
| | | | | | | | | We need to introduce a separate BdrvNextIterator struct that can keep more state than just the current BDS in order to avoid using the bs->blk pointer. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: User BdrvChild callback for device nameKevin Wolf2016-05-191-2/+20
| | | | | | | | | In order to get rid of bs->blk for bdrv_get_device_name() and bdrv_get_device_or_node_name(), ask all parents for their name and simply pick the first one. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Use BdrvChild callbacks for change_media/resizeKevin Wolf2016-05-191-13/+26
| | | | | | | | | | We want to get rid of BlockDriverState.blk in order to allow multiple BlockBackends per BDS. Converting the device callbacks in block.c (which assume a single BlockBackend) to per-child callbacks gets us rid of the first few instances. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* Revert "block: Forbid I/O throttling on nodes with multiple parents for 2.6"Kevin Wolf2016-05-191-6/+0Star
| | | | | | | | | | | | | | | This reverts commit 76b223200ef4fb09dd87f0e213159795eb68e7a5. Now that I/O throttling is fully done on the BlockBackend level, there is no reason any more to block I/O throttling for nodes with multiple parents as the parents don't influence each other any more. Conflicts: block.c Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* block: Remove bdrv_move_feature_fields()Kevin Wolf2016-05-191-30/+0Star
| | | | | | | | | | bdrv_move_feature_fields() and swap_feature_fields() are empty now, they can be removed. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* block: Decouple throttling from BlockDriverStateKevin Wolf2016-05-191-34/+0Star
| | | | | | | | | | | | | | | This moves the throttling related part of the BDS life cycle management to BlockBackend. The throttling group reference is now kept even when no medium is inserted. With this commit, throttling isn't disabled and then re-enabled any more during graph reconfiguration. This fixes the temporary breakage of I/O throttling when used with live snapshots or block jobs that manipulate the graph. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* block: Move I/O throttling configuration functions to BlockBackendKevin Wolf2016-05-191-1/+1
| | | | | | Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* block: Move throttling fields from BDS to BBKevin Wolf2016-05-191-11/+11
| | | | | | | | | | This patch changes where the throttling state is stored (used to be the BlockDriverState, now it is the BlockBackend), but it doesn't actually make it a BB level feature yet. For example, throttling is still disabled when the BDS is detached from the BB. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* block: Make sure throttled BDSes always have a BBKevin Wolf2016-05-191-0/+14
| | | | | | | | | | | | | | | | It was already true in principle that a throttled BDS always has a BB attached, except that the order of operations while attaching or detaching a BDS to/from a BB wasn't careful enough. This commit breaks graph manipulations while I/O throttling is enabled. It would have been possible to keep things working with some temporary hacks, but quite cumbersome, so it's not worth the hassle. We'll fix things again in a minute. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
* quorum: implement bdrv_add_child() and bdrv_del_child()Wen Congyang2016-05-121-4/+4
| | | | | | | | | | | Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Changlong Xie <xiecl.fnst@cn.fujitsu.com> Message-id: 1462865799-19402-3-git-send-email-xiecl.fnst@cn.fujitsu.com Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
* Add new block driver interface to add/delete a BDS's childWen Congyang2016-05-121-0/+49
| | | | | | | | | | | | | | In some cases, we want to take a quorum child offline, and take another child online. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Changlong Xie <xiecl.fnst@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 1462865799-19402-2-git-send-email-xiecl.fnst@cn.fujitsu.com Signed-off-by: Max Reitz <mreitz@redhat.com>
* block: Inactivate all childrenFam Zheng2016-05-121-11/+36
| | | | | | | | | | | | | | | | Currently we only inactivate the top BDS. Actually bdrv_inactivate should be the opposite of bdrv_invalidate_cache. Recurse into the whole subtree instead. Because a node may have multiple parents, and because once BDRV_O_INACTIVE is set for a node, further writes are not allowed, we cannot interleave flag settings and .bdrv_inactivate calls (that may submit write to other nodes in a graph) within a single pass. Therefore two passes are used here. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Invalidate all childrenFam Zheng2016-05-121-6/+14
| | | | | | | | | | | Currently we only recurse to bs->file, which will miss the children in quorum and VMDK. Recurse into the whole subtree to avoid that. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Remove BlockDriver.bdrv_read/writeKevin Wolf2016-05-121-2/+0Star
| | | | | | | | | There are no block drivers left that implement the old .bdrv_read/write interface, so it can be removed now. This gets us rid of the corresponding emulation functions, too. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
* block: introduce bdrv_no_throttling_begin/endPaolo Bonzini2016-05-121-1/+0Star
| | | | | | | | | | | Extract the handling of throttling from bdrv_flush_io_queue. These new functions will soon become BdrvChildRole callbacks, as they can be generalized to "beginning of drain" and "end of drain". Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Forbid I/O throttling on nodes with multiple parents for 2.6Kevin Wolf2016-04-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | As the patches to move I/O throttling to BlockBackend didn't make it in time for the 2.6 release, but the release adds new ways of configuring VMs whose behaviour would change once the move is done, we need to outlaw such configurations temporarily. The problem exists whenever a BDS has more users than just its BB, for example it is used as a backing file for another node. (This wasn't possible in 2.5 yet as we introduced node references to specify a backing file only recently.) In these cases, the throttling would apply to these other users now, but after moving throttling to the BlockBackend the other users wouldn't be throttled any more. This patch prevents making new references to a throttled node as well as using monitor commands to throttle a node with multiple parents. Compared to 2.5 this changes behaviour in some corner cases where references were allowed before, like bs->file or Quorum children. It seems reasonable to assume that users didn't use I/O throttling on such low level nodes. With the upcoming move of throttling into BlockBackend, such configurations won't be possible anyway. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* block: Remove bdrv_(set_)enable_write_cache()Kevin Wolf2016-03-301-16/+0Star
| | | | | | | | | | | The only remaining users were block jobs (mirror and backup) which unconditionally enabled WCE on the BlockBackend of the target image. As these block jobs don't go through BlockBackend for their I/O requests, they aren't affected by this setting anyway but always get a writeback mode, so that call can be removed. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Remove BDRV_O_CACHE_WBKevin Wolf2016-03-301-46/+2Star
| | | | | | | | | | | | | | | | | | | The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Remove bdrv_parse_cache_flags()Kevin Wolf2016-03-301-22/+7Star
| | | | | | | All users are converted to bdrv_parse_cache_mode() now. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* qemu-io: Use bdrv_parse_cache_mode() in reopen_f()Kevin Wolf2016-03-301-12/+6Star
| | | | | | | | | | | | | We must forbid changing the WCE flag in bdrv_reopen() in the same patch, as otherwise the behaviour would change so that the flag takes precedence over the explicitly specified option. The correct value of the WCE flag depends on the BlockBackend user (e.g. guest device) and isn't a decision that the QMP client makes, so this change is what we want. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block/qapi: Use blk_enable_write_cache()Kevin Wolf2016-03-301-1/+1
| | | | | | | | | | | | | | | | | | Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Move enable_write_cache to BB levelKevin Wolf2016-03-301-9/+17
| | | | | | | | | | | | | | Whether a write cache is used or not is a decision that concerns the user (e.g. the guest device) rather than the backend. It was already logically part of the BB level as bdrv_move_feature_fields() always kept it on top of the BDS tree; with this patch, the core of it (the actual flag and the additional flushes) is also implemented there. Direct callers of bdrv_open() must pass BDRV_O_CACHE_WB now if bs doesn't have a BlockBackend attached. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: Add bdrv_parse_cache_mode()Kevin Wolf2016-03-301-0/+17
| | | | | | | | It's like bdrv_parse_cache_flags(), except that writethrough mode isn't included in the flags, but returned as a separate bool. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* block: move encryption deprecation warning into qcow codeDaniel P. Berrange2016-03-301-7/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a couple of releases we have been warning Encrypted images are deprecated Support for them will be removed in a future release. You can use 'qemu-img convert' to convert your image to an unencrypted one. This warning was issued by system emulators, qemu-img, qemu-nbd and qemu-io. Such a broad warning was issued because the original intention was to rip out all the code for dealing with encryption inside the QEMU block layer APIs. The new block encryption framework used for the LUKS driver does not rely on the unloved block layer API for encryption keys, instead using the QOM 'secret' object type. It is thus no longer appropriate to warn about encryption unconditionally. When the qcow/qcow2 drivers are converted to use the new encryption framework too, it will be practical to keep AES-CBC support present for use in qemu-img, qemu-io & qemu-nbd to allow for interoperability with older QEMU versions and liberation of data from existing encrypted qcow2 files. This change moves the warning out of the generic block code and into the qcow/qcow2 drivers. Further, the warning is set to only appear when running the system emulators, since qemu-img, qemu-io, qemu-nbd are expected to support qcow2 encryption long term now that the maint burden has been eliminated. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: add flag to indicate that no I/O will be performedDaniel P. Berrange2016-03-301-2/+3
| | | | | | | | | | | | | | | | | When opening an image it is useful to know whether the caller intends to perform I/O on the image or not. In the case of encrypted images this will allow the block driver to avoid having to prompt for decryption keys when we merely want to query header metadata about the image. eg qemu-img info This flag is enforced at the top level only, since even if we don't want todo I/O on the 'qcow2' file payload, the underlying 'file' driver will still need todo I/O to read the qcow2 header, for example. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Reject writethrough mode except at the rootKevin Wolf2016-03-301-0/+7
| | | | | | | | | | | | | | | | | | | Writethrough mode is going to become a BlockBackend feature rather than a BDS one, so forbid it in places where we won't be able to support it when the code finally matches the envisioned design. We only allowed setting the cache mode of non-root nodes after the 2.5 release, so we're still free to make this change. The target of block jobs is now always opened in a writeback mode because it doesn't have a BlockBackend attached. This makes more sense anyway because block jobs know when to flush. If the graph is modified on job completion, the original cache mode moves to the new root, so for the guest device writethough always stays enabled if it was configured this way. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* block: Make backing files always writebackKevin Wolf2016-03-301-2/+3
| | | | | | | | | First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* block: Remove dirty bitmaps from bdrv_move_feature_fields()Kevin Wolf2016-03-301-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes dirty bitmaps from following a BlockBackend in graph changes to sticking with the node they were created at. For the full discussion, read the following mailing list thread: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields() https://lists.nongnu.org/archive/html/qemu-block/2016-02/msg00745.html In summary, the justification for this change is: * When moving the dirty bitmap to the top of the tree was introduced in bdrv_append() in commit a9fc4408, it didn't actually have any effect because there could never be a bitmap in use when bdrv_append() was called (op blockers would prevent this). This is still true today for all internal uses of dirty bitmaps. * Support for user-defined dirty bitmaps was introduced in 2.4, but we discouraged users from using it because we didn't consider it ready yet. Moreover, in 2.5, the bdrv_swap() removal introduced a bug that left dangling pointers if a dirty bitmap was present (the anchors of the dirty bitmap were swapped, but the back link in the first element wasn't updated), so it didn't even work correctly. * block-dirty-bitmap-add takes an arbitrary node name, even if no BlockBackend is attached. This suggests that it is a node level operation and not a BlockBackend one. Consequently, there is no reason for dirty bitmaps to stay with a BlockBackend that was attached to the node they were created for. * It was suggested that block-dirty-bitmap-add could track the node if a node name was specified, and track the BlockBackend if the device name was specified. This would however be inconsistent with other QMP commands. Commands that accept both device and node names currently interpret the device name just as an alias for the current root node of that BlockBackend. * Dirty bitmaps have a name that is only unique amongst the bitmaps in a specific node. Moving bitmaps could lead to name clashes. Automatic renaming would involve too much magic. * Persistent bitmaps are stored in a specific node. Moving them around automatically might be at least surprising, but it would probably also become a real problem because that would have to happen atomically without the management tool knowing of the operation. At the end of the day it seems to be very clear that it was a mistake to include dirty bitmaps in bdrv_move_feature_fields(). The functionality of moving bitmaps and/or attaching them to a BlockBackend instead will probably be needed, but it should be done with a new explicit QMP command or option. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* block: Remove copy-on-read from bdrv_move_feature_fields()Kevin Wolf2016-03-301-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ever since we first introduced bdrv_append() in commit 8802d1fd ('qapi: Introduce blockdev-group-snapshot-sync command'), the copy-on-read flag was moved to the new top layer when taking a snapshot. The only problem is that it doesn't make a whole lot of sense. The use case for manually enabled CoR is to avoid reading data twice from a slow remote image, so we want to save it to a local overlay, say an ISO image accessed via HTTP to a local qcow2 overlay. When taking a snapshot, we end up with a backing chain like this: http <- local.qcow2 <- snap_overlay.qcow2 There is no point in doing CoR from local.qcow2 into snap_overlay.qcow2, we just want to keep copying data from the remote source into local.qcow2. The other use case of CoR is in the context of streaming, which isn't very interesting for bdrv_move_feature_fields() because op blockers prevent this combination. This patch makes the copy-on-read flag stay on the image for which it was originally set and prevents it from being propagated to the new overlay. It is no longer intended to move CoR to the BlockBackend level. In order for this to make sense, we also need to keep the respective image read-write. As a side effect of these changes, creating a live snapshot image (as opposed to using an existing externally created one) on top of a COR block device works now. It used to fail because it tried to open its backing file both read-only and with COR. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* block: Remove bdrv_make_anon()Kevin Wolf2016-03-301-12/+3Star
| | | | | | | | | | | | The call in hmp_drive_del() is dead code because blk_remove_bs() is called a few lines above. The only other remaining user is bdrv_delete(), which only abuses bdrv_make_anon() to remove it from the named nodes list. This path inlines the list entry removal into bdrv_delete() and removes bdrv_make_anon(). Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
* util: move declarations out of qemu-common.hVeronia Bahaa2016-03-221-1/+2
| | | | | | | | | | Move declarations out of qemu-common.h for functions declared in utils/ files: e.g. include/qemu/path.h for utils/path.c. Move inline functions out of qemu-common.h and into new files (e.g. include/qemu/bcd.h) Signed-off-by: Veronia Bahaa <veroniabahaa@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* block: Use BdrvChild in BlockBackendKevin Wolf2016-03-171-13/+34
| | | | Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Remove bdrv_states listMax Reitz2016-03-171-28/+3Star
| | | | | | Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Use bdrv_next() instead of bdrv_statesMax Reitz2016-03-171-6/+6
| | | | | | | | | There is no point in manually iterating through the bdrv_states list when there is bdrv_next(). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Rewrite bdrv_next()Max Reitz2016-03-171-3/+14
| | | | | | | | | | Instead of using the bdrv_states list, iterate over all the BlockDriverStates attached to BlockBackends, and over all the monitor-owned BDSs afterwards (except for those attached to a BB). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Move some bdrv_*_all() functions to BBMax Reitz2016-03-171-20/+0Star
| | | | | | | Move bdrv_commit_all() and bdrv_flush_all() to the BlockBackend level. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* block: Drop BB name from bad option errorMax Reitz2016-03-171-3/+3
| | | | | | | | | | | | | | | The information which BB is concerned does not seem useful enough to justify its existence in most other place (which may be related to qemu printing the -drive parameter in question anyway, and for blockdev-add the attribution is naturally unambiguous). Furthermore, as of a future patch, bdrv_get_device_name(bs) will always return the empty string before bdrv_open_inherit() returns. Therefore, just dropping that information seems to be the best course of action. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-22 17:42:13 +0100