riscv/qemu - qemu - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Michael Tokarev	2abc22e639	block/curl: rewrite http header parsing function Existing code was long, unclear and twisty. This also relaxes the rules a tiny bit: allows to have whitespace before header name and colon and makes the header value match to be case-insensitive. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Nir Soffer	d05ae948cc	Consider discard option when writing zeros When opening an image with discard=off, we punch hole in the image when writing zeroes, making the image sparse. This breaks users that want to ensure that writes cannot fail with ENOSPACE by using fully allocated images[1]. bdrv_co_pwrite_zeroes() correctly disables BDRV_REQ_MAY_UNMAP if we opened the child without discard=unmap or discard=on. But we don't go through this function when accessing the top node. Move the check down to bdrv_co_do_pwrite_zeroes() which seems to be used in all code paths. This change implements the documented behavior, punching holes only when opening the image with discard=on or discard=unmap. This may not be the best default but can improve it later. The test depends on a file system supporting discard, deallocating the entire file when punching hole with the length of the entire file. Tested with xfs, ext4, and tmpfs. [1] https://lists.nongnu.org/archive/html/qemu-discuss/2024-06/msg00003.html Signed-off-by: Nir Soffer <nsoffer@redhat.com> Message-id: 20240628202058.1964986-3-nsoffer@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>	2 years ago
Akihiko Odaki	7b1070a7e1	Revert "meson: Propagate gnutls dependency" This reverts commit `3eacf70bb5`. It was only needed because of duplicate objects caused by declare_dependency(link_whole: ...), and can be dropped now that meson.build specifies objects and dependencies separately for the internal dependencies. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20240524-objects-v1-2-07cbbe96166b@daynix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	2 years ago
Kevin Wolf	bd385a5298	qcow2: Don't open data_file with BDRV_O_NO_IO One use case for 'qemu-img info' is verifying that untrusted images don't reference an unwanted external file, be it as a backing file or an external data file. To make sure that calling 'qemu-img info' can't already have undesired side effects with a malicious image, just don't open the data file at all with BDRV_O_NO_IO. If nothing ever tries to do I/O, we don't need to have it open. This changes the output of iotests case 061, which used 'qemu-img info' to show that opening an image with an invalid data file fails. After this patch, it succeeds. Replace this part of the test with a qemu-io call, but keep the final 'qemu-img info' to show that the invalid data file is correctly displayed in the output. Fixes: CVE-2024-4467 Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com>	2 years ago
Akihiko Odaki	e9c9d8dc3b	block/file-posix: Drop ifdef for macOS versions older than 12.0 macOS versions older than 12.0 are no longer supported. docs/about/build-platforms.rst says: > Support for the previous major version will be dropped 2 years after > the new major version is released or when the vendor itself drops > support, whichever comes first. macOS 12.0 was released 2021: https://www.apple.com/newsroom/2021/10/macos-monterey-is-now-available/ Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240629-macos-v1-3-6e70a6b700a0@daynix.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>	2 years ago
Paolo Bonzini	d656aaa136	block: rename former bdrv_file_open callbacks Since there is no bdrv_file_open callback anymore, rename the implementations so that they end with "_open" instead of "_file_open". NFS is the exception because all the functions are named nfs_file_*. Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	3 years ago
Paolo Bonzini	44b424dc4a	block: remove separate bdrv_file_open callback bdrv_file_open and bdrv_open are completely equivalent, they are never checked except to see which one to invoke. So merge them into a single one. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	3 years ago
Stefan Hajnoczi	3ab0f063e5	crypto/block: drop qcrypto_block_open() n_threads argument The n_threads argument is no longer used since the previous commit. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240527155851.892885-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Prasad Pandit	24687abf23	linux-aio: add IO_CMD_FDSYNC command support Libaio defines IO_CMD_FDSYNC command to sync all outstanding asynchronous I/O operations, by flushing out file data to the disk storage. Enable linux-aio to submit such aio request. When using aio=native without fdsync() support, QEMU creates pthreads, and destroying these pthreads results in TLB flushes. In a real-time guest environment, TLB flushes cause a latency spike. This patch helps to avoid such spikes. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Prasad Pandit <pjp@fedoraproject.org> Message-ID: <20240425070412.37248-1-ppandit@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Fiona Ebner	10b1e09ed3	block/copy-before-write: use uint64_t for timeout in nanoseconds rather than the uint32_t for which the maximum is slightly more than 4 seconds and larger values would overflow. The QAPI interface allows specifying the number of seconds, so only values 0 to 4 are safe right now, other values lead to a much lower timeout than a user expects. The block_copy() call where this is used already takes a uint64_t for the timeout, so no change required there. Fixes: `6db7fd1ca9` ("block/copy-before-write: implement cbw-timeout option") Reported-by: Friedrich Weber <f.weber@proxmox.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240429141934.442154-1-f.ebner@proxmox.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Denis V. Lunev via	b67e353863	block: drop force_dup parameter of raw_reconfigure_getfd() Since commit `72373e40fb`, this parameter is always passed as 'false' from the caller. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> Message-ID: <20240430170213.148558-1-den@openvz.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Vladimir Sementsov-Ogievskiy	0fd05c8d80	qapi: blockdev-backup: add discard-source parameter Add a parameter that enables discard-after-copy. That is mostly useful in "push backup with fleecing" scheme, when source is snapshot-access format driver node, based on copy-before-write filter snapshot-access API: [guest] [snapshot-access] ~~ blockdev-backup ~~> [backup target] \| \| \| root \| file v v [copy-before-write] \| \| \| file \| target v v [active disk] [temp.img] In this case discard-after-copy does two things: - discard data in temp.img to save disk space - avoid further copy-before-write operation in discarded area Note that we have to declare WRITE permission on source in copy-before-write filter, for discard to work. Still we can't take it unconditionally, as it will break normal backup from RO source. So, we have to add a parameter and pass it thorough bdrv_open flags. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Acked-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240313152822.626493-5-vsementsov@yandex-team.ru> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Vladimir Sementsov-Ogievskiy	006e845b5a	block/copy-before-write: create block_copy bitmap in filter node Currently block_copy creates copy_bitmap in source node. But that is in bad relation with .independent_close=true of copy-before-write filter: source node may be detached and removed before .bdrv_close() handler called, which should call block_copy_state_free(), which in turn should remove copy_bitmap. That's all not ideal: it would be better if internal bitmap of block-copy object is not attached to any node. But that is not possible now. The simplest solution is just create copy_bitmap in filter node, where anyway two other bitmaps are created. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240313152822.626493-4-vsementsov@yandex-team.ru> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Vladimir Sementsov-Ogievskiy	507175197b	block/copy-before-write: support unligned snapshot-discard First thing that crashes on unligned access here is bdrv_reset_dirty_bitmap(). Correct way is to align-down the snapshot-discard request. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240313152822.626493-3-vsementsov@yandex-team.ru> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Vladimir Sementsov-Ogievskiy	137b4d4bd5	block/copy-before-write: fix permission In case when source node does not have any parents, the condition still works as required: backup job do create the parent by block_job_create -> block_job_add_bdrv -> bdrv_root_attach_child Still, in this case checking @perm variable doesn't work, as backup job creates the root blk with empty permissions (as it rely on CBW filter to require correct permissions and don't want to create extra conflicts). So, we should not check @perm. The hack may be dropped entirely when transactional insertion of filter (when we don't try to recalculate permissions in intermediate state, when filter does conflict with original parent of the source node) merged (old big series "[PATCH v5 00/45] Transactional block-graph modifying API"[1] and it's current in-flight part is "[PATCH v8 0/7] blockdev-replace"[2]) [1] https://patchew.org/QEMU/20220330212902.590099-1-vsementsov@openvz.org/ [2] https://patchew.org/QEMU/20231017184444.932733-1-vsementsov@yandex-team.ru/ Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240313152822.626493-2-vsementsov@yandex-team.ru> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Alexander Ivanov	7d99ae59a2	blockcommit: Reopen base image as RO after abort If a blockcommit is aborted the base image remains in RW mode, that leads to a fail of subsequent live migration. How to reproduce: $ virsh snapshot-create-as vm snp1 --disk-only * write something to the disk inside the guest * $ virsh blockcommit vm vda --active --shallow && virsh blockjob vm vda --abort $ lsof /vzt/vm.qcow2 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME qemu-syst 433203 root 45u REG 253,0 1724776448 133 /vzt/vm.qcow2 $ cat /proc/433203/fdinfo/45 pos: 0 flags: 02140002 <==== The last 2 means RW mode If the base image is in RW mode at the end of blockcommit and was in RO mode before blockcommit, reopen the base BDS in RO. Signed-off-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20240404091136.129811-1-alexander.ivanov@virtuozzo.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>	2 years ago
Markus Armbruster	29ad187c1c	block/vmdk: Improve error messages on extent write error vmdk_init_extent() reports blk_co_pwrite() failure to its caller as An IO error has occurred The errno code returned by blk_co_pwrite() is lost. Improve this to failed to write VMDK <what>: <description of errno> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240513141703.549874-4-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>	2 years ago
Paolo Bonzini	ae9433fb11	meson: do not query modules before they are processed Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	2 years ago
Paolo Bonzini	0241e0feda	meson: remove unnecessary reference to libm libm is linked into all targets via libqemuutil, no need to specify it explicitly. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	2 years ago
Thomas Huth	a22a97d805	block/ssh: Use URI parsing code from glib Since version 2.66, glib has useful URI parsing functions, too. Use those instead of the QEMU-internal ones to be finally able to get rid of the latter. While we're at it, also emit a warning when encountering unknown parameters in the URI, so that the users have a chance to detect their typos or other mistakes. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Message-ID: <20240418101056.302103-13-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Thomas Huth	f8b74fc55d	block/nfs: Use URI parsing code from glib Since version 2.66, glib has useful URI parsing functions, too. Use those instead of the QEMU-internal ones to be finally able to get rid of the latter. While we're at it, slightly rephrase one of the error messages: Use "Invalid value..." instead of "Illegal value..." since the latter rather sounds like the users were breaking a law here. Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20240418101056.302103-12-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Thomas Huth	ad97c011dc	block/nbd: Use URI parsing code from glib Since version 2.66, glib has useful URI parsing functions, too. Use those instead of the QEMU-internal ones to be finally able to get rid of the latter. The g_uri_get_host() also takes care of removing the square brackets from IPv6 addresses, so we can drop that part of the QEMU code now, too. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20240418101056.302103-11-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Thomas Huth	3413c6628b	block/gluster: Use URI parsing code from glib Since version 2.66, glib has useful URI parsing functions, too. Use those instead of the QEMU-internal ones to be finally able to get rid of the latter. Since g_uri_get_path() returns a const pointer, we also need to tweak the parameter of parse_volume_options() (where we use the result of g_uri_get_path() as input). Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20240418101056.302103-10-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Philippe Mathieu-Daudé	f9cc8cfdf3	block/qcow2-bitmap: Replace g_memdup() by g_memdup2() Per https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538 The old API took the size of the memory to duplicate as a guint, whereas most memory functions take memory sizes as a gsize. This made it easy to accidentally pass a gsize to g_memdup(). For large values, that would lead to a silent truncation of the size from 64 to 32 bits, and result in a heap area being returned which is significantly smaller than what the caller expects. This can likely be exploited in various modules to cause a heap buffer overflow. Replace g_memdup() by the safer g_memdup2() wrapper. Trivially safe because the argument was directly from sizeof. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20210903174510.751630-6-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>	5 years ago
Philippe Mathieu-Daudé	2d9cbbea64	block/gluster: Remove deprecated RDMA protocol handling GlusterFS+RDMA has been deprecated 8 years ago in commit `0552ff2465` ("block/gluster: deprecate rdma support"): gluster volfile server fetch happens through unix and/or tcp, it doesn't support volfile fetch over rdma. The rdma code may actually mislead, so to make sure things do not break, for now we fallback to tcp when requested for rdma, with a warning. If you are wondering how this worked all these days, its the gluster libgfapi code which handles anything other than unix transport as socket/tcp, sad but true. Besides, the whole RDMA subsystem was deprecated in commit `e9a54265f5` ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") released in v8.2. Cc: Prasanna Kumar Kalever <prasanna.kalever@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240328130255.52257-4-philmd@linaro.org>	2 years ago
Philippe Mathieu-Daudé	a95921f171	qapi: Inline and remove QERR_DEVICE_HAS_NO_MEDIUM definition Address the comment added in commit `4629ed1e98` ("qerror: Finally unused, clean up"), from 2015: /* * These macros will go away, please don't use * in new code, and do not add new ones! */ Mechanical transformation using sed, and manual cleanup. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240312141343.3168265-4-armbru@redhat.com>	2 years ago
Kevin Wolf	e193d4bdb8	block: Remove unnecessary NULL check in bdrv_pad_request() Coverity complains that the check introduced in commit `3f934817` suggests that qiov could be NULL and we dereference it before reaching the check. In fact, all of the callers pass a non-NULL pointer, so just remove the misleading check. Resolves: Coverity CID 1542668 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240327192750.204197-1-kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>	2 years ago
Fiona Ebner	bac09b093e	block-backend: fix edge case in bdrv_next_cleanup() where BDS associated to BB changes Same rationale as for commit "block-backend: fix edge case in bdrv_next() where BDS associated to BB changes". The block graph might change between the bdrv_next() call and the bdrv_next_cleanup() call, so it could be that the associated BDS is not the same that was referenced previously anymore. Instead, rely on bdrv_next() to set it->bs to the BDS it referenced and unreference that one in any case. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-4-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Fiona Ebner	f6d38c9f6d	block-backend: fix edge case in bdrv_next() where BDS associated to BB changes The old_bs variable in bdrv_next() is currently determined by looking at the old block backend. However, if the block graph changes before the next bdrv_next() call, it might be that the associated BDS is not the same that was referenced previously. In that case, the wrong BDS is unreferenced, leading to an assertion failure later: > bdrv_unref: Assertion `bs->refcnt > 0' failed. In particular, this can happen in the context of bdrv_flush_all(), when polling for bdrv_co_flush() in the generated co-wrapper leads to a graph change (for example with a stream block job [0]). A racy reproducer: > #!/bin/bash > rm -f /tmp/backing.qcow2 > rm -f /tmp/top.qcow2 > ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M > ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2 > ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2 > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": "node0" } } > {"execute": "quit"} > EOF [0]: > #0 bdrv_replace_child_tran (child=..., new_bs=..., tran=...) > #1 bdrv_replace_node_noperm (from=..., to=..., auto_skip=..., tran=..., errp=...) > #2 bdrv_replace_node_common (from=..., to=..., auto_skip=..., detach_subchain=..., errp=...) > #3 bdrv_drop_filter (bs=..., errp=...) > #4 bdrv_cor_filter_drop (cor_filter_bs=...) > #5 stream_prepare (job=...) > #6 job_prepare_locked (job=...) > #7 job_txn_apply_locked (fn=..., job=...) > #8 job_do_finalize_locked (job=...) > #9 job_exit (opaque=...) > #10 aio_bh_poll (ctx=...) > #11 aio_poll (ctx=..., blocking=...) > #12 bdrv_poll_co (s=...) > #13 bdrv_flush (bs=...) > #14 bdrv_flush_all () > #15 do_vm_stop (state=..., send_stop=...) > #16 vm_shutdown () Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-3-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Stefan Reiter	3f934817c8	block/io: accept NULL qiov in bdrv_pad_request Some operations, e.g. block-stream, perform reads while discarding the results (only copy-on-read matters). In this case, they will pass NULL as the target QEMUIOVector, which will however trip bdrv_pad_request, since it wants to extend its passed vector. In particular, this is the case for the blk_co_preadv() call in stream_populate(). If there is no qiov, no operation can be done with it, but the bytes and offset still need to be updated, so the subsequent aligned read will actually be aligned and not run into an assertion failure. In particular, this can happen when the request alignment of the top node is larger than the allocated part of the bottom node, in which case padding becomes necessary. For example: > ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M -o cluster_size=32768 > ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2 > ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2 > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "blockdev-add", "arguments": { "driver": "compress", "file": "node0", "node-name": "node1" } } > {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": "node1" } } > EOF Originally-by: Stefan Reiter <s.reiter@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> [FE: do update bytes and offset in any case add reproducer to commit message] Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Abhiram Tilak	52df1a5b61	qemu-img: Fix Column Width and Improve Formatting in snapshot list When running the command `qemu-img snapshot -l SNAPSHOT` the output of VM_CLOCK (measures the offset between host and VM clock) cannot to accommodate values in the order of thousands (4-digit). This line [1] hints on the problem. Additionally, the column width for the VM_CLOCK field was reduced from 15 to 13 spaces in commit `b39847a5` in line [2], resulting in a shortage of space. [1]: https://gitlab.com/qemu-project/qemu/-/blob/master/block/qapi.c?ref_type=heads#L753 [2]: https://gitlab.com/qemu-project/qemu/-/blob/master/block/qapi.c?ref_type=heads#L763 This patch restores the column width to 15 spaces and makes adjustments to the affected iotests accordingly. Furthermore, addresses a potential source of confusion by removing whitespace in column headers. Example, VM CLOCK is modified to VM_CLOCK. Additionally a '--' symbol is introduced when ICOUNT returns no output for clarity. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2062 Fixes: `b39847a505` ("migration: introduce icount field for snapshots") Signed-off-by: Abhiram Tilak <atp.exp@gmail.com> Message-ID: <20240123050354.22152-2-atp.exp@gmail.com> [kwolf: Fixed up qemu-iotests 261 and 286] Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Kevin Wolf	ae5a40e858	mirror: Don't call job_pause_point() under graph lock Calling job_pause_point() while holding the graph reader lock potentially results in a deadlock: bdrv_graph_wrlock() first drains everything, including the mirror job, which pauses it. The job is only unpaused at the end of the drain section, which is when the graph writer lock has been successfully taken. However, if the job happens to be paused at a pause point where it still holds the reader lock, the writer lock can't be taken as long as the job is still paused. Mark job_pause_point() as GRAPH_UNLOCKED and fix mirror accordingly. Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-28125 Fixes: `004915a96a` ("block: Protect bs->backing with graph_lock") Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240313153000.33121-1-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Zhao Liu	46ff64a826	error: Move ERRP_GUARD() to the beginning of the function Since the commit `05e385d2a9` ("error: Move ERRP_GUARD() to the beginning of the function"), there are new codes that don't put ERRP_GUARD() at the beginning of the functions. As stated in the commit 05e385d2a9: "include/qapi/error.h advises to put ERRP_GUARD() right at the beginning of the function, because only then can it guard the whole function.", so clean up the few spots disregarding the advice. Inspired-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240312060337.3240965-1-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	76db0ea3bf	block/vmdk: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The vmdk_parse_extents() passes @errp to error_prepend(), and its @errp is from vmdk_open(). Though, vmdk_open(), as a BlockDriver.bdrv_open(), gets the @errp parameter which is pointer of its caller's local_err, to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Fam Zheng <fam@euphon.net> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240311033822.3142585-13-zhao1.liu@linux.intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	f5ec96c92e	block/vdi: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The vdi_co_do_create() passes @errp to error_prepend() without ERRP_GUARD(), and its @errp parameter is so widely sourced that it is necessary to protect it with ERRP_GUARD(). To avoid the potential issues as [1] said, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Stefan Weil <sw@weilnetz.de> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240311033822.3142585-12-zhao1.liu@linux.intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	ce33d85d45	block/snapshot: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. In block/snapshot.c, there are 2 functions passing @errp to error_prepend() without ERRP_GUARD(): - bdrv_all_delete_snapshot() - bdrv_all_goto_snapshot() As the APIs exposed in include/block/snapshot.h, they could be called by other modules. To avoid potential issues as [1] said, add missing ERRP_GUARD() at the beginning of these 2 functions. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20240311033822.3142585-11-zhao1.liu@linux.intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	c66eec9094	block/qed: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The bdrv_qed_co_invalidate_cache() passes @errp to error_prepend() without ERRP_GUARD(). Though it is a BlockDriver.bdrv_co_invalidate_cache() method, and currently its @errp parameter only points to callers' local_err, to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240311033822.3142585-10-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	d13e3b4670	block/qcow2: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. In block/qcow2.c, there are 2 functions passing @errp to error_prepend() without ERRP_GUARD(): - qcow2_co_create() - qcow2_co_truncate() There are too many possible callers to check the impact of the defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD(). Therefore, to avoid the issue like [1] said, add missing ERRP_GUARD() at their beginning. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20240311033822.3142585-9-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	e1081e3bff	block/qcow2-bitmap: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The qcow2_co_can_store_new_dirty_bitmap() passes @errp to error_prepend(). As a BlockDriver.bdrv_co_can_store_new_dirty_bitmap method, it's called by bdrv_co_can_store_new_dirty_bitmap(). Its caller is not being called anywhere, but as the API in include/block/block-io.h, we can't ensure what kind of @errp future users will pass in. To avoid potential issues as [1] said, add missing ERRP_GUARD() at the beginning of qcow2_co_can_store_new_dirty_bitmap(). [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Cc: John Snow <jsnow@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20240311033822.3142585-8-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	ed46217d5d	block/nvme: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. In nvme.c, there are 3 functions passing @errp to error_prepend() without ERRP_GUARD(): - nvme_init_queue() - nvme_create_queue_pair() - nvme_identify() All these 3 functions take their @errp parameters from the nvme_file_open(), which is a BlockDriver.bdrv_nvme() method and its @errp points to its caller's local_err. Though these 3 cases haven't trigger the issue like [1] said, to follow the requirement of @errp, add missing ERRP_GUARD() at their beginning. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Fam Zheng <fam@euphon.net> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240311033822.3142585-7-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	c835ca0027	block/nbd: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The nbd_co_do_receive_one_chunk() passes @errp to error_prepend() without ERRP_GUARD(), and though its @errp parameter points to its caller's local_err, to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: Eric Blake <eblake@redhat.com> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20240311033822.3142585-6-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Zhao Liu	c79eabc5e5	block/copy-before-write: Fix missing ERRP_GUARD() for error_prepend() As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1]. The cbw_open() passes @errp to error_prepend() without ERRP_GUARD(). Though it is the BlockDriver.bdrv_open() method, and currently its @errp parameter only points to callers' local_err, to follow the requirement of @errp, add missing ERRP_GUARD() at the beginning of this function. [1]: Issue description in the commit message of commit `ae7c80a7bd` ("error: New macro ERRP_GUARD()"). Cc: John Snow <jsnow@redhat.com> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Hanna Reitz <hreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20240311033822.3142585-5-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>	2 years ago
Hyman Huang	35286daeca	block: Support detached LUKS header creation using qemu-img Even though a LUKS header might be created with cryptsetup, qemu-img should be enhanced to accommodate it as well. Add the 'detached-header' option to specify the creation of a detached LUKS header. This is how it is used: $ qemu-img create --object secret,id=sec0,data=abc123 -f luks > -o cipher-alg=aes-256,cipher-mode=xts -o key-secret=sec0 > -o detached-header=true header.luks Using qemu-img or cryptsetup tools to query information of an LUKS header image as follows: Assume a detached LUKS header image has been created by: $ dd if=/dev/zero of=test-header.img bs=1M count=32 $ dd if=/dev/zero of=test-payload.img bs=1M count=1000 $ cryptsetup luksFormat --header test-header.img test-payload.img > --force-password --type luks1 Header image information could be queried using cryptsetup: $ cryptsetup luksDump test-header.img or qemu-img: $ qemu-img info 'json:{"driver":"luks","file":{"filename": > "test-payload.img"},"header":{"filename":"test-header.img"}}' When using qemu-img, keep in mind that the entire disk information specified by the JSON-format string above must be supplied on the commandline; if not, an overlay check will reveal a problem with the LUKS volume check logic. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [changed to pass 'cflags' to block_crypto_co_create_generic] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Hyman Huang	d0112eb415	block: Support detached LUKS header creation using blockdev-create Firstly, enable the ability to choose the block device containing a detachable LUKS header by adding the 'header' parameter to BlockdevCreateOptionsLUKS. Secondly, when formatting the LUKS volume with a detachable header, truncate the payload volume to length without a header size. Using the qmp blockdev command, create the LUKS volume with a detachable header as follows: 1. add the secret to lock/unlock the cipher stored in the detached LUKS header $ virsh qemu-monitor-command vm '{"execute":"object-add", > "arguments":{"qom-type": "secret", "id": "sec0", "data": "foo"}}' 2. create a header img with 0 size $ virsh qemu-monitor-command vm '{"execute":"blockdev-create", > "arguments":{"job-id":"job0", "options":{"driver":"file", > "filename":"/path/to/detached_luks_header.img", "size":0 }}}' 3. add protocol blockdev node for header $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments": {"driver":"file", "filename": > "/path/to/detached_luks_header.img", "node-name": > "detached-luks-header-storage"}}' 4. create a payload img with 0 size $ virsh qemu-monitor-command vm '{"execute":"blockdev-create", > "arguments":{"job-id":"job1", "options":{"driver":"file", > "filename":"/path/to/detached_luks_payload_raw.img", "size":0}}}' 5. add protocol blockdev node for payload $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments": {"driver":"file", "filename": > "/path/to/detached_luks_payload_raw.img", "node-name": > "luks-payload-raw-storage"}}' 6. do the formatting with 128M size $ virsh qemu-monitor-command c81_node1 '{"execute":"blockdev-create", > "arguments":{"job-id":"job2", "options":{"driver":"luks", "header": > "detached-luks-header-storage", "file":"luks-payload-raw-storage", > "size":134217728, "preallocation":"full", "key-secret":"sec0" }}}' Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Hyman Huang	d74523a3b3	crypto: Modify the qcrypto_block_create to support creation flags Expand the signature of qcrypto_block_create to enable the formation of LUKS volumes with detachable headers. To accomplish that, introduce QCryptoBlockCreateFlags to instruct the creation process to set the payload_offset_sector to 0. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Hyman Huang	433957bb7f	qapi: Make parameter 'file' optional for BlockdevCreateOptionsLUKS To support detached LUKS header creation, make the existing 'file' field in BlockdevCreateOptionsLUKS optional. Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Hyman Huang	9ad5c4e7ee	crypto: Support LUKS volume with detached header By enhancing the LUKS driver, it is possible to implement the LUKS volume with a detached header. Normally a LUKS volume has a layout: disk: \| header \| key material \| disk payload data \| With a detached LUKS header, you need 2 disks so getting: disk1: \| header \| key material \| disk2: \| disk payload data \| There are a variety of benefits to doing this: * Secrecy - the disk2 cannot be identified as containing LUKS volume since there's no header * Control - if access to the disk1 is restricted, then even if someone has access to disk2 they can't unlock it. Might be useful if you have disks on NFS but want to restrict which host can launch a VM instance from it, by dynamically providing access to the header to a designated host * Flexibility - your application data volume may be a given size and it is inconvenient to resize it to add encryption.You can store the LUKS header separately and use the existing storage volume for payload * Recovery - corruption of a bit in the header may make the entire payload inaccessible. It might be convenient to take backups of the header. If your primary disk header becomes corrupt, you can unlock the data still by pointing to the backup detached header Take the raw-format image as an example to introduce the usage of the LUKS volume with a detached header: 1. prepare detached LUKS header images $ dd if=/dev/zero of=test-header.img bs=1M count=32 $ dd if=/dev/zero of=test-payload.img bs=1M count=1000 $ cryptsetup luksFormat --header test-header.img test-payload.img > --force-password --type luks1 2. block-add a protocol blockdev node of payload image $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-1-storage", "driver":"file", > "filename":"test-payload.img"}}' 3. block-add a protocol blockdev node of LUKS header as above. $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-2-storage", "driver":"file", > "filename": "test-header.img" }}' 4. object-add the secret for decrypting the cipher stored in LUKS header above $ virsh qemu-monitor-command vm '{"execute":"object-add", > "arguments":{"qom-type":"secret", "id": > "libvirt-2-storage-secret0", "data":"abc123"}}' 5. block-add the raw-drived blockdev format node $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-1-format", "driver":"raw", > "file":"libvirt-1-storage"}}' 6. block-add the luks-drived blockdev to link the raw disk with the LUKS header by specifying the field "header" $ virsh qemu-monitor-command vm '{"execute":"blockdev-add", > "arguments":{"node-name":"libvirt-2-format", "driver":"luks", > "file":"libvirt-1-format", "header":"libvirt-2-storage", > "key-secret":"libvirt-2-format-secret0"}}' 7. hot-plug the virtio-blk device finally $ virsh qemu-monitor-command vm '{"execute":"device_add", > "arguments": {"num-queues":"1", "driver":"virtio-blk-pci", > "drive": "libvirt-2-format", "id":"virtio-disk2"}}' Starting a VM with a LUKS volume with detached header is somewhat similar to hot-plug in that both maintaining the same json command while the starting VM changes the "blockdev-add/device_add" parameters to "blockdev/device". Signed-off-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Kevin Wolf	10b2393e5e	blkio: Respect memory-alignment for bounce buffer allocations blkio_alloc_mem_region() requires that the requested buffer size is a multiple of the memory-alignment property. If it isn't, the allocation fails with a return value of -EINVAL. Fix the call in blkio_resize_bounce_pool() to make sure the requested size is properly aligned. I observed this problem with vhost-vdpa, which requires page aligned memory. As the virtio-blk device behind it still had 512 byte blocks, we got bs->bl.request_alignment = 512, but actually any request that needed a bounce buffer and was not aligned to 4k would fail without this fix. Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240131173140.42398-1-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Hanna Czenczek	ad89367202	block-backend: Allow concurrent context changes Since AioContext locks have been removed, a BlockBackend's AioContext may really change at any time (only exception is that it is often confined to a drained section, as noted in this patch). Therefore, blk_get_aio_context() cannot rely on its root node's context always matching that of the BlockBackend. In practice, whether they match does not matter anymore anyway: Requests can be sent to BDSs from any context, so anyone who requests the BB's context should have no reason to require the root node to have the same context. Therefore, we can and should remove the assertion to that effect. In addition, because the context can be set and queried from different threads concurrently, it has to be accessed with atomic operations. Buglink: https://issues.redhat.com/browse/RHEL-19381 Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20240202144755.671354-2-hreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	2 years ago
Richard W.M. Jones	615eaeab3d	block/blkio: Make s->mem_region_alignment be 64 bits With GCC 14 the code failed to compile on i686 (and was wrong for any version of GCC): ../block/blkio.c: In function ‘blkio_file_open’: ../block/blkio.c:857:28: error: passing argument 3 of ‘blkio_get_uint64’ from incompatible pointer type [-Wincompatible-pointer-types] 857 \| &s->mem_region_alignment); \| ^~~~~~~~~~~~~~~~~~~~~~~~ \| \| \| size_t * {aka unsigned int } In file included from ../block/blkio.c:12: /usr/include/blkio.h:49:67: note: expected ‘uint64_t ’ {aka ‘long long unsigned int ’} but argument is of type ‘size_t ’ {aka ‘unsigned int ’} 49 \| int blkio_get_uint64(struct blkio b, const char name, uint64_t value); \| ~~~~~~~~~~^~~~~ Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Message-id: 20240130122006.2977938-1-rjones@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>	2 years ago

1 2 3 4 5 ...

6161 Commits (98e77e3dd8dd6e7aa9a7dffa60f49c8c8a49d4e3)