[PATCH] mailmap: Fix Andrey Drobyshev author email

2023-09-26 Thread andrey . drobyshev--- via
(VM) via Qemu-devel Stefan Weil Stefan Weil via +Andrey Drobyshev Andrey Drobyshev via # Next, replace old addresses by a more recent one. Aleksandar Markovic -- 2.41.0

[PATCH v3 1/8] qemu-img: rebase: stop when reaching EOF of old backing file

2023-09-19 Thread Andrey Drobyshev via
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed furt

[PATCH v3 5/8] qemu-img: rebase: avoid unnecessary COW operations

2023-09-19 Thread Andrey Drobyshev via
When rebasing an image from one backing file to another, we need to compare data from old and new backings. If the diff between that data happens to be unaligned to the target cluster size, we might end up doing partial writes, which would lead to copy-on-write and additional IO. Consider the fol

[PATCH v3 8/8] iotests: add tests for "qemu-img rebase" with compression

2023-09-19 Thread Andrey Drobyshev via
The test cases considered so far: 314 (new test suite): 1. Check that compression mode isn't compatible with "-f raw" (raw format doesn't support compression). 2. Check that rebasing an image onto no backing file preserves the data and writes the copied clusters actually compressed. 3. Same

[PATCH v3 4/8] qemu-img: add chunk size parameter to compare_buffers()

2023-09-19 Thread Andrey Drobyshev via
Add @chsize param to the function which, if non-zero, would represent the chunk size to be used for comparison. If it's zero, then BDRV_SECTOR_SIZE is used as default chunk size, which is the previous behaviour. In particular, we're going to use this param in img_rebase() to make the write reques

[PATCH v3 2/8] qemu-iotests: 024: add rebasing test case for overlay_size > backing_size

2023-09-19 Thread Andrey Drobyshev via
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev Reviewed-by: Denis V. Lunev Reviewed

[PATCH v3 6/8] iotests/{024, 271}: add testcases for qemu-img rebase

2023-09-19 Thread Andrey Drobyshev via
As the previous commit changes the logic of "qemu-img rebase" (it's using write alignment now), let's add a couple more test cases which would ensure it works correctly. In particular, the following scenarios: 024: add test case for rebase within one backing chain when the overlay cluster si

[PATCH v3 0/8] qemu-img: rebase: add compression support

2023-09-19 Thread Andrey Drobyshev via
v2 --> v3: * Patch 3/8: fixed logic in the if statement, so that we align on blk when blk_old_backing == NULL; * Patch 4/8: comment fix; * Patch 5/8: comment fix; dropped redundant "if (blk_new_backing)" statements. v2: https://lists.nongnu.org/archive/html/qemu-block/2023-09/msg00448.htm

[PATCH v3 3/8] qemu-img: rebase: use backing files' BlockBackend for buffer alignment

2023-09-19 Thread Andrey Drobyshev via
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for the data read from the old and new backing files are aligned using BlockDriverState (or BlockBackend later on) referring to the target image. However, this isn't quite right, because buf_new is only being used for reading from

[PATCH v3 7/8] qemu-img: add compression option to rebase subcommand

2023-09-19 Thread Andrey Drobyshev via
If we rebase an image whose backing file has compressed clusters, we might end up wasting disk space since the copied clusters are now uncompressed. In order to have better control over this, let's add "--compress" option to the "qemu-img rebase" command. Note that this option affects only the cl

[PATCH v2 0/8] qemu-img: rebase: add compression support

2023-09-15 Thread Andrey Drobyshev via
v1 --> v2: * Choose proper BlockBackend when aligning buf_old; * Add new patch ("qemu-img: add chunk size parameter to compare_buffers()"); * Rework write alignment logic; now writes are aligned to either subcluster or cluster size, depending on whether compressionis enabled; * Add new pa

[PATCH v2 5/8] qemu-img: rebase: avoid unnecessary COW operations

2023-09-15 Thread Andrey Drobyshev via
When rebasing an image from one backing file to another, we need to compare data from old and new backings. If the diff between that data happens to be unaligned to the target cluster size, we might end up doing partial writes, which would lead to copy-on-write and additional IO. Consider the fol

[PATCH v2 8/8] iotests: add tests for "qemu-img rebase" with compression

2023-09-15 Thread Andrey Drobyshev via
The test cases considered so far: 314 (new test suite): 1. Check that compression mode isn't compatible with "-f raw" (raw format doesn't support compression). 2. Check that rebasing an image onto no backing file preserves the data and writes the copied clusters actually compressed. 3. Same

[PATCH v2 6/8] iotests/{024, 271}: add testcases for qemu-img rebase

2023-09-15 Thread Andrey Drobyshev via
As the previous commit changes the logic of "qemu-img rebase" (it's using write alignment now), let's add a couple more test cases which would ensure it works correctly. In particular, the following scenarios: 024: add test case for rebase within one backing chain when the overlay cluster si

[PATCH v2 1/8] qemu-img: rebase: stop when reaching EOF of old backing file

2023-09-15 Thread Andrey Drobyshev via
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed furt

[PATCH v2 3/8] qemu-img: rebase: use backing files' BlockBackend for buffer alignment

2023-09-15 Thread Andrey Drobyshev via
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for the data read from the old and new backing files are aligned using BlockDriverState (or BlockBackend later on) referring to the target image. However, this isn't quite right, because buf_new is only being used for reading from

[PATCH v2 4/8] qemu-img: add chunk size parameter to compare_buffers()

2023-09-15 Thread Andrey Drobyshev via
Add @chsize param to the function which, if non-zero, would represent the chunk size to be used for comparison. If it's zero, then BDRV_SECTOR_SIZE is used as default chunk size, which is the previous behaviour. In particular, we're going to use this param in img_rebase() to make the write reques

[PATCH v2 7/8] qemu-img: add compression option to rebase subcommand

2023-09-15 Thread Andrey Drobyshev via
If we rebase an image whose backing file has compressed clusters, we might end up wasting disk space since the copied clusters are now uncompressed. In order to have better control over this, let's add "--compress" option to the "qemu-img rebase" command. Note that this option affects only the cl

[PATCH v2 2/8] qemu-iotests: 024: add rebasing test case for overlay_size > backing_size

2023-09-15 Thread Andrey Drobyshev via
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev Reviewed-by: Denis V. Lunev Reviewed

[PATCH v2 4/3] qemu-iotests/197: use more generic commands for formats other than qcow2

2023-09-07 Thread Andrey Drobyshev via
In the previous commit e2f938265e0 ("tests/qemu-iotests/197: add testcase for CoR with subclusters") we've introduced a new testcase for copy-on-read with subclusters. Test 197 always forces qcow2 as the top image, but allows backing image to be in any format. That last test case didn't meet thes

[PATCH v3 1/2] block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status()

2023-09-07 Thread Andrey Drobyshev via
Functions qcow2_get_host_offset(), get_cluster_offset(), vmdk_co_block_status() explicitly report compressed cluster types when data is compressed. However, this information is never passed further. Let's make use of it by adding new BDRV_BLOCK_COMPRESSED flag for bdrv_block_status(), so that cal

[PATCH v3 0/2] qemu-img: map: implement support for compressed clusters

2023-09-07 Thread Andrey Drobyshev via
v2 --> v3: * Make "compressed" field mandatory, not optional; * Adjust field description in qapi/block-core.json; * Squash patch 3 into patch 2 so that failing tests don't break bisect; * Update even more tests' outputs now that the field is mandatory. v2: https://lists.nongnu.org/archive/

[PATCH v2 0/3] block: align CoR requests to subclusters

2023-07-11 Thread Andrey Drobyshev via
v1 --> v2: * Fixed line indentation; * Fixed wording in a comment; * Added R-b. v1: https://lists.nongnu.org/archive/html/qemu-block/2023-06/msg00606.html Andrey Drobyshev (3): block: add subcluster_size field to BlockDriverInfo block/io: align requests to subcluster_size tests/qemu-iote

[PATCH v2 2/3] block/io: align requests to subcluster_size

2023-07-11 Thread Andrey Drobyshev via
When target image is using subclusters, and we align the request during copy-on-read, it makes sense to align to subcluster_size rather than cluster_size. Otherwise we end up with unnecessary allocations. This commit renames bdrv_round_to_clusters() to bdrv_round_to_subclusters() and utilizes sub

[PATCH v2 1/3] block: add subcluster_size field to BlockDriverInfo

2023-07-11 Thread Andrey Drobyshev via
This is going to be used in the subsequent commit as requests alignment (in particular, during copy-on-read). This value only makes sense for the formats which support subclusters (currently QCOW2 only). If this field isn't set by driver's own bdrv_get_info() implementation, we simply set it equa

[PATCH v2 3/3] tests/qemu-iotests/197: add testcase for CoR with subclusters

2023-07-11 Thread Andrey Drobyshev via
Add testcase which checks that allocations during copy-on-read are performed on the subcluster basis when subclusters are enabled in target image. This testcase also triggers the following assert with previous commit not being applied, so we check that as well: qemu-io: ../block/io.c:1236: bdrv_c

[PATCH v2 0/3] qemu-img: map: implement support for compressed clusters

2023-07-06 Thread Andrey Drobyshev via
v1 --> v2: * Add vmdk format to the 1st commit. Tweak commit message accordingly; * Make "compressed" field in MapEntry optional. v1: https://lists.nongnu.org/archive/html/qemu-block/2023-06/msg00184.html Andrey Drobyshev (3): block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status()

[PATCH v2 3/3] qemu-iotests: update expected tests output to contain "compressed" field

2023-07-06 Thread Andrey Drobyshev via
The previous commit adds "compressed" boolean field to JSON output of "qemu-img map" command. Let's tweak expected tests output accordingly. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/122.out| 84 tests/qemu-iotests/154.out| 194

[PATCH v2 1/3] block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status()

2023-07-06 Thread Andrey Drobyshev via
Functions qcow2_get_host_offset(), get_cluster_offset(), vmdk_co_block_status() explicitly report compressed cluster types when data is compressed. However, this information is never passed further. Let's make use of it by adding new BDRV_BLOCK_COMPRESSED flag for bdrv_block_status(), so that cal

[PATCH v2 2/3] qemu-img: map: report compressed data blocks

2023-07-06 Thread Andrey Drobyshev via
Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_CO

[PATCH 3/3] tests/qemu-iotests/197: add testcase for CoR with subclusters

2023-06-26 Thread Andrey Drobyshev via
Add testcase which checks that allocations during copy-on-read are performed on the subcluster basis when subclusters are enabled in target image. This testcase also triggers the following assert with previous commit not being applied, so we check that as well: qemu-io: ../block/io.c:1236: bdrv_c

[PATCH 2/3] block/io: align requests to subcluster_size

2023-06-26 Thread Andrey Drobyshev via
When target image is using subclusters, and we align the request during copy-on-read, it makes sense to align to subcluster_size rather than cluster_size. Otherwise we end up with unnecessary allocations. This commit renames bdrv_round_to_clusters() to bdrv_round_to_subclusters() and utilizes sub

[PATCH 0/3] block: align CoR requests to subclusters

2023-06-26 Thread Andrey Drobyshev via
This series makes IO requests performed with copy-on-read to be aligned to subclusters rather than clusters. It also affects mirror job requests alignment. The initial reason for that change is the following crash discovered: qemu-img create -f qcow2 base.qcow2 64K qemu-img create -f qcow2 -o e

[PATCH 1/3] block: add subcluster_size field to BlockDriverInfo

2023-06-26 Thread Andrey Drobyshev via
This is going to be used in the subsequent commit as requests alignment (in particular, during copy-on-read). This value only makes sense for the formats which support subclusters (currently QCOW2 only). If this field isn't set by driver's own bdrv_get_info() implementation, we simply set it equa

[PATCH 3/3] qemu-iotests: update expected tests output to contain "compressed" field

2023-06-07 Thread Andrey Drobyshev via
The previous commit adds "compressed" boolean field to JSON output of "qemu-img map" command. Let's tweak expected tests output accordingly. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/122.out| 84 tests/qemu-iotests/154.out| 194

[PATCH 1/3] block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status()

2023-06-07 Thread Andrey Drobyshev via
Functions qcow2_get_host_offset(), get_cluster_offset() explicitly report compressed cluster types when data is compressed. However, this information is never passed further. Let's make use of it by adding new BDRV_BLOCK_COMPRESSED flag for bdrv_block_status(), so that caller may know that the da

[PATCH 0/3] qemu-img: map: implement support for compressed clusters

2023-06-07 Thread Andrey Drobyshev via
This series adds "compressed" field to the output of "qemu-img map" command, specifying whether or not data block is compressed. Only JSON output mode is affected. With this applied, output looks like so: # qemu-img create -f qcow2 img.qcow2 192K # qemu-io -c "write -c -P 0xaa 0 64K" img.qcow2 #

[PATCH 2/3] qemu-img: map: report compressed data blocks

2023-06-07 Thread Andrey Drobyshev via
Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_CO

[PATCH 0/6] qemu-img: rebase: add compression support

2023-06-01 Thread Andrey Drobyshev via
This series is adding [-c | --compress] option to "qemu-img rebase" command, which might prove useful for saving some disk space when, for instance, manipulating chains of backup images. Along the way I had to make a couple of minor improvements. The first 2 patches are a bug fix + corresponding

[PATCH 1/6] qemu-img: rebase: stop when reaching EOF of old backing file

2023-06-01 Thread Andrey Drobyshev via
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed furt

[PATCH 5/6] qemu-img: add compression option to rebase subcommand

2023-06-01 Thread Andrey Drobyshev via
If we rebase an image whose backing file has compressed clusters, we might end up wasting disk space since the copied clusters are now uncompressed. In order to have better control over this, let's add "--compress" option to the "qemu-img rebase" command. Note that this option affects only the cl

[PATCH 4/6] qemu-img: rebase: avoid unnecessary COW operations

2023-06-01 Thread Andrey Drobyshev via
When rebasing an image from one backing file to another, we need to compare data from old and new backings. If the diff between that data happens to be unaligned to the target cluster size, we might end up doing partial writes, which would lead to copy-on-write and additional IO. Consider the fol

[PATCH 6/6] iotests: add test 314 for "qemu-img rebase" with compression

2023-06-01 Thread Andrey Drobyshev via
The test cases considered so far: 1. Check that compression mode isn't compatible with "-f raw" (raw format doesn't support compression). 2. Check that rebasing an image onto no backing file preserves the data and writes the copied clusters actually compressed. 3. Same as 2, but with a raw b

[PATCH 2/6] qemu-iotests: 024: add rebasing test case for overlay_size > backing_size

2023-06-01 Thread Andrey Drobyshev via
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/024 | 57

[PATCH 3/6] qemu-img: rebase: use backing files' BlockBackend for buffer alignment

2023-06-01 Thread Andrey Drobyshev via
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for the data read from the old and new backing files are aligned using BlockDriverState (or BlockBackend later on) referring to the target image. However, this isn't quite right, because target image is only being written to and ha

[PATCH v2 1/2] qemu-img: rebase: stop when reaching EOF of old backing file

2023-05-25 Thread Andrey Drobyshev via
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed furt

[PATCH v2 0/2] qemu-img: fix getting stuck in infinite loop on in-chain rebase

2023-05-25 Thread Andrey Drobyshev via
v1 -> v2: * Avoid breaking the loop just yet, as the offsets beyond the old backing size need to be explicitly zeroed; * Amend the commit message accordingly; * Alter the added test case to take the last zeroed cluster into consideration. v1: https://lists.nongnu.org/archive/html/qe

[PATCH v2 2/2] qemu-iotests: 024: add rebasing test case for overlay_size > backing_size

2023-05-25 Thread Andrey Drobyshev via
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/024 | 57

[PATCH 1/2] qemu-img: rebase: stop when reaching EOF of old backing file

2023-05-23 Thread Andrey Drobyshev via
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and break the lo

[PATCH 2/2] qemu-iotests: 024: add rebasing test case for overlay_size > backing_size

2023-05-23 Thread Andrey Drobyshev via
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev --- tests/qemu-iotests/024 | 48

[PATCH 0/2] qemu-img: fix getting stuck in infinite loop on

2023-05-23 Thread Andrey Drobyshev via
Consider the following in-chain rebase case: qemu-img create -f qcow2 base.qcow2 $(( 64 * 4 ))k qemu-img create -f qcow2 -o backing_file=base.qcow2,backing_fmt=qcow2 inc1.qcow2 $(( 64 * 4 ))k qemu-img create -f qcow2 -o backing_file=inc1.qcow2,backing_fmt=qcow2 inc2.qcow2 $(( 64 * 5 ))k qemu-img

[PATCH v2] qga-win: choose the right libpcre version to include in MSI package

2022-12-13 Thread Andrey Drobyshev via
According to GLib changelog [1], since version 2.73.2 GLib is using libpcre2 instead of libpcre. As a result, qemu-ga MSI installation fails due to missing DLL when linked with the newer GLib. This commit makes wixl to put the right libpcre version into the MSI bundle: either libpcre-1.dll or lib

[PATCH v2 0/2] qga: improve "syslog" domain logging

2022-11-29 Thread Andrey Drobyshev via
These patches extend QGA logging interface, primarily under Windows guests. They enable QGA to write to Windows event log, much like syslog() on *nix. In addition we get rid of hardcoded log level used by ga_log(). v2: * Close event_log handle when doing cleanup_agent() * Fix switch cases indent

[PATCH v2 2/2] qga: map GLib log levels to system levels

2022-11-29 Thread Andrey Drobyshev via
This patch translates GLib-specific log levels to system ones, so that they may be used by both *nix syslog() (as a "priority" argument) and Windows ReportEvent() (as a "wType" argument). Currently the only codepath to write to "syslog" domain is slog() function. However, this patch allows the in

[PATCH v2 1/2] qga-win: add logging to Windows event log

2022-11-29 Thread Andrey Drobyshev via
This commit allows QGA to write to Windows event log using Win32 API's ReportEvent() [1], much like syslog() under *nix guests. In order to generate log message definitions we use a very basic message text file [2], so that every QGA's message gets ID 1. The tools "windmc" and "windres" respectiv

[PATCH 1/2] qga-win: add logging to Windows event log

2022-11-28 Thread Andrey Drobyshev via
This commit allows QGA to write to Windows event log using Win32 API's ReportEvent() [1], much like syslog() under *nix guests. In order to generate log message definitions we use a very basic message text file [2], so that every QGA's message gets ID 1. The tools "windmc" and "windres" respectiv

[PATCH 2/2] qga: map GLib log levels to system levels

2022-11-28 Thread Andrey Drobyshev via
This patch translates GLib-specific log levels to system ones, so that they may be used by both *nix syslog() (as a "priority" argument) and Windows ReportEvent() (as a "wType" argument). Currently the only codepath to write to "syslog" domain is slog() function. However, this patch allows the in

[PATCH 0/2] qga: improve "syslog" domain logging

2022-11-28 Thread Andrey Drobyshev via
These patches extend QGA logging interface, primarily under Windows guests. They enable QGA to write to Windows event log, much like syslog() on *nix. In addition we get rid of hardcoded log level used by ga_log(). Andrey Drobyshev (2): qga-win: add logging to Windows event log qga: map GLib