Patchew URL: https://patchew.org/QEMU/20200423221707.477404-1-ebl...@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Patchew URL: https://patchew.org/QEMU/20200423221707.477404-1-ebl...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
Patchew URL: https://patchew.org/QEMU/20200423221707.477404-1-ebl...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was
In v2:
- new patch 1 [Max]
- split off and reword unrelated change into patch 3 [Max]
- improve the test: grep for items of interest, check $? [Max]
- improve commit message explaining partial failure [Max]
Eric Blake (3):
block: Add blk_new_with_bs() helper
qcow2: Allow resize of images with
There are several callers that need to create a new block backend from
an existing BDS; make the task slightly easier with a common helper
routine.
Suggested-by: Max Reitz
Signed-off-by: Eric Blake
---
include/sysemu/block-backend.h | 2 ++
block/block-backend.c | 23
Our comment did not actually match the code. Rewrite the comment to
be less sensitive to any future changes to qcow2-bitmap.c that might
implement scenarios that we currently reject.
Signed-off-by: Eric Blake
---
block/qcow2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
During testing of the vhost-user-blk reconnect functionality the qemu
SIGSEGV was triggered:
start qemu as:
x86_64-softmmu/qemu-system-x86_64 -m 1024M -M q35 \
-object
memory-backend-file,id=ram-node0,size=1024M,mem-path=/dev/shm/qemu,share=on \
-numa node,cpus=0,memdev=ram-node0 \
Since disconnect can happen at any time during initialization not all
vring buffers (for instance used vring) can be intialized successfully.
If the buffer was not initialized then vhost_memory_unmap call will lead
to SIGSEGV. Add checks for the vring address value before calling unmap.
Also add
Introduce new wrappers to set/reset guest notifiers for the virtio
device in the vhost device module:
vhost_dev_assign_guest_notifiers
->set_guest_notifiers(..., ..., true);
vhost_dev_drop_guest_notifiers
->set_guest_notifiers(..., ..., false);
This is a preliminary step to refactor
Add "--simulate-disconnect-stage" option for the testing purposes.
This option can be used to test the vhost-user reconnect functionality:
./vhost-user-blk ... --simulate-disconnect-stage=
In this case the daemon will "crash" in the middle of the VHOST comands
communication. Case nums are as
During vhost-user reconnect functionality testing the following assert
was hit:
qemu-system-x86_64: chardev/char-socket.c:125:
qemu_chr_socket_restart_timer: Assertion `!s->reconnect_timer' failed.
Aborted (core dumped)
This is observed only if the connection is closed by the vhost-user-blk
In case of the vhost-user devices the daemon can be killed at any
moment. Since QEMU supports the reconnet functionality the guest
notifiers should be reset and disabled after "disconnect" event. The
most issues were found if the "disconnect" event happened during vhost
device initialization step.
If vhost-user daemon is used as a backend for the vhost device, then we
should consider a possibility of disconnect at any moment. If such
disconnect happened in the vhost_migration_log() routine the vhost
device structure will be clean up.
At the start of the vhost_migration_log() function there
During vhost-user reconnect functionality we hit several issues, if
vhost-user-blk daemon is "crashed" or made disconnect during vhost
initialization. The general scenario is as follows:
- vhost start routine is called
- vhost write failed due to SIGPIPE
- this call the disconnect routine
Hi
On Thu, Apr 23, 2020 at 8:43 PM Dima Stepanov wrote:
>
> During testing of the vhost-user-blk reconnect functionality the qemu
> SIGSEGV was triggered:
> start qemu as:
> x86_64-softmmu/qemu-system-x86_64 -m 1024M -M q35 \
>-object
>
Hi
On Thu, Apr 23, 2020 at 8:41 PM Dima Stepanov wrote:
>
> During vhost-user reconnect functionality testing the following assert
> was hit:
> qemu-system-x86_64: chardev/char-socket.c:125:
> qemu_chr_socket_restart_timer: Assertion `!s->reconnect_timer' failed.
> Aborted (core dumped)
On 22.04.20 15:31, Philippe Mathieu-Daudé wrote:
> Fix warning reported by Clang static code analyzer:
>
> block.c:3167:5: warning: Value stored to 'ret' is never read
> ret = bdrv_fill_options(, filename, , _err);
> ^ ~
>
On 22.04.20 15:31, Philippe Mathieu-Daudé wrote:
> Fix warning reported by Clang static code analyzer:
>
> CC blockdev.o
> blockdev.c:2744:5: warning: Value stored to 'ret' is never read
> ret = blk_truncate(blk, size, false, PREALLOC_MODE_OFF, errp);
> ^
On 23.04.20 17:01, Kevin Wolf wrote:
> The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
> image is possibly preallocated and then the zero flag is added to all
> clusters. This means that a copy-on-write operation may be needed when
> writing to these clusters, despite
On 23.04.20 17:01, Kevin Wolf wrote:
> When extending the size of an image that has a backing file larger than
> its old size, make sure that the backing file data doesn't become
> visible in the guest, but the added area is properly zeroed out.
>
> Consider the following scenario where the
On 4/23/20 12:21 PM, Max Reitz wrote:
The previous comment was incorrect as well, but actually
qcow2_truncate_bitmaps_check() doesn’t return an error when there is any
bitmap, but only if there are non-active bitmaps, or active bitmaps that
cannot be modified. So for non-disabled bitmaps, we
On Wed 22 Apr 2020 02:06:56 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> 17.03.2020 21:16, Alberto Garcia wrote:
>> Setting the QCOW_OFLAG_ZERO bit of the L2 entry is forbidden if an
>> image has subclusters. Instead, the individual 'all zeroes' bits must
>> be used.
>>
>> Signed-off-by:
On 23.04.20 16:35, Eric Blake wrote:
> On 4/23/20 8:55 AM, Max Reitz wrote:
>> On 22.04.20 22:53, Eric Blake wrote:
>>> We originally refused to allow resize of images with internal
>>> snapshots because the v2 image format did not require the tracking of
>>> snapshot size, making it impossible to
Am 30.03.2020 um 16:18 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi all!
>
> There is an idea to make NBD protocol extension to support 64bit
> write-zero/discard/block-status commands (commands, which doesn't
> transfer user data). It's needed to increase performance of zeroing
> large
On Wed 22 Apr 2020 02:38:54 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
> 17.03.2020 21:16, Alberto Garcia wrote:
>> l2meta_cow_start() and l2meta_cow_end() are not necessarily
>> cluster-aligned if the image has subclusters, so update the
>> calculation of old_start and old_end to guarantee that
On 4/23/20 11:04 AM, Kevin Wolf wrote:
Hmm. When we get block status, it is very easy to tell that something reads
as zero when the qcow2 file has the zero bit set, but when the qcow2 file
does not have the zero bit set, we have to then query the format layer
whether it reads as zeros (which
Am 23.04.2020 um 17:36 hat Eric Blake geschrieben:
> On 4/23/20 10:01 AM, Kevin Wolf wrote:
> > The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
> > image is possibly preallocated and then the zero flag is added to all
> > clusters. This means that a copy-on-write operation
Am 23.04.2020 um 17:18 hat Eric Blake geschrieben:
> On 4/23/20 10:01 AM, Kevin Wolf wrote:
> > If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
> > qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
> > undo any previous preallocation, but just adds the zero
On 4/23/20 10:01 AM, Kevin Wolf wrote:
The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
image is possibly preallocated and then the zero flag is added to all
clusters. This means that a copy-on-write operation may be needed when
writing to these clusters, despite having
Am 30.03.2020 um 16:18 hat Vladimir Sementsov-Ogievskiy geschrieben:
> We are generally moving to int64_t for both offset and bytes paramaters
> on all io paths. Convert tracked requests now.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/block/block_int.h | 4 ++--
>
On 4/23/20 10:01 AM, Kevin Wolf wrote:
When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
Consider the following scenario where the overlay is
On 4/23/20 10:01 AM, Kevin Wolf wrote:
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previous preallocation, but just adds the zero flag to all
relevant L2 entries. If an external data file is
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
---
tests/qemu-iotests/274 | 157 ++
tests/qemu-iotests/274.out | 260 +
tests/qemu-iotests/group | 1 +
3 files changed, 418 insertions(+)
create mode 100755 tests/qemu-iotests/274
The BDRV_REQ_ZERO_WRITE is currently implemented in a way that first the
image is possibly preallocated and then the zero flag is added to all
clusters. This means that a copy-on-write operation may be needed when
writing to these clusters, despite having used preallocation, negating
one of the
For regular files, we always get BDRV_REQ_ZERO_WRITE behaviour from the
OS, so we can advertise the flag and just ignore it.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
block/file-posix.c | 4
1 file changed,
The raw format driver can simply forward the flag and let its bs->file
child take care of actually providing the zeros.
Signed-off-by: Kevin Wolf
Reviewed-by: Max Reitz
Reviewed-by: Eric Blake
---
block/raw-format.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Now that block drivers can support flags for .bdrv_co_truncate, expose
the parameter in the node level interfaces bdrv_co_truncate() and
bdrv_truncate().
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
We want to keep TEST_IMG for the full path of the main test image, but
filter_testfiles() must be called for other test images before replacing
other things like the image format because the test directory path could
contain the format as a substring.
Insert a filter_testfiles() call between
Now that node level interface bdrv_truncate() supports passing request
flags to the block driver, expose this on the BlockBackend level, too.
Signed-off-by: Kevin Wolf
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Alberto Garcia
Reviewed-by: Max Reitz
---
When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
Consider the following scenario where the overlay is shorter than its
backing file:
If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
undo any previous preallocation, but just adds the zero flag to all
relevant L2 entries. If an external data file is in use, a write_zeroes
request to the data
This adds a new BdrvRequestFlags parameter to the .bdrv_co_truncate()
driver callbacks, and a supported_truncate_flags field in
BlockDriverState that allows drivers to advertise support for request
flags in the context of truncate.
For now, we always pass 0 and no drivers declare support for any
v6:
- qcow2: Don't round up end offset [Eric]
- qcow2: Use different error messages for different error paths
- Request BDRV_REQ_ZERO_WRITE only if the backing file actually covers
(part of) the new area (fix regression from v3) [Max]
- New patch: Forward ZERO_WRITE flag for full preallocation
On 4/23/20 8:55 AM, Max Reitz wrote:
On 22.04.20 22:53, Eric Blake wrote:
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size
On Wed 22 Apr 2020 08:09:53 PM CEST, Vladimir Sementsov-Ogievskiy wrote:
>> There's currently an inconsistency now that I think of it: if an image
>> has subclusters and QCOW_OFLAG_ZERO set then qcow2_get_cluster_type()
>> returns QCOW2_CLUSTER_ZERO_* but qcow2_get_subcluster_type() returns
>>
On 4/23/20 8:23 AM, Kevin Wolf wrote:
So qcow2_cluster_zeroize() seems to accept the unaligned tail. It would
still set the zero flag for the partial last cluster and for the
external data file, bdrv_co_pwrite_zeroes() would have the correct size.
Then I'm in favor of NOT rounding the tail.
On 22.04.20 22:53, Eric Blake wrote:
> We originally refused to allow resize of images with internal
> snapshots because the v2 image format did not require the tracking of
> snapshot size, making it impossible to safely revert to a snapshot
> with a different size than the current view of the
On 23.04.20 15:25, Kevin Wolf wrote:
> Am 23.04.2020 um 12:53 hat Max Reitz geschrieben:
>> On 22.04.20 17:21, Kevin Wolf wrote:
>>> If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
>>> qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
>>> undo any previous
Am 23.04.2020 um 12:53 hat Max Reitz geschrieben:
> On 22.04.20 17:21, Kevin Wolf wrote:
> > If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
> > qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
> > undo any previous preallocation, but just adds the zero
Am 22.04.2020 um 18:14 hat Eric Blake geschrieben:
> On 4/22/20 10:58 AM, Kevin Wolf wrote:
>
> > > > @@ -4214,6 +4215,35 @@ static int coroutine_fn
> > > > qcow2_co_truncate(BlockDriverState *bs, int64_t offset,
> > > >g_assert_not_reached();
> > > >}
> > > > +if ((flags
Am 23.04.2020 um 13:14 hat Max Reitz geschrieben:
> On 22.04.20 17:21, Kevin Wolf wrote:
> > When extending the size of an image that has a backing file larger than
> > its old size, make sure that the backing file data doesn't become
> > visible in the guest, but the added area is properly zeroed
Am 23.04.2020 um 11:41 hat Max Reitz geschrieben:
> On 22.04.20 17:21, Kevin Wolf wrote:
> > This adds a new BdrvRequestFlags parameter to the .bdrv_co_truncate()
> > driver callbacks, and a supported_truncate_flags field in
> > BlockDriverState that allows drivers to advertise support for request
On 22.04.20 17:21, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/274 | 157 ++
> tests/qemu-iotests/274.out | 260 +
> tests/qemu-iotests/group | 1 +
> 3 files changed, 418 insertions(+)
> create mode
On 22.04.20 17:21, Kevin Wolf wrote:
> We want to keep TEST_IMG for the full path of the main test image, but
> filter_testfiles() must be called for other test images before replacing
> other things like the image format because the test directory path could
> contain the format as a substring.
>
On 22.04.20 17:21, Kevin Wolf wrote:
> When extending the size of an image that has a backing file larger than
> its old size, make sure that the backing file data doesn't become
> visible in the guest, but the added area is properly zeroed out.
>
> Consider the following scenario where the
On Thu, Apr 23, 2020 at 12:53:48PM +0200, janine.schnei...@fau.de wrote:
> Hy again,
>
> okay so now we have an easy way out just in case.
> But I still want to build an DLL and/or a shared library for integration
> into the tool. I want the tool to be platform independent and I was
> already
On 22.04.20 17:21, Kevin Wolf wrote:
> For regular files, we always get BDRV_REQ_ZERO_WRITE behaviour from the
> OS, so we can advertise the flag and just ignore it.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Alberto Garcia
> ---
>
On 22.04.20 17:21, Kevin Wolf wrote:
> The raw format driver can simply forward the flag and let its bs->file
> child take care of actually providing the zeros.
>
> Signed-off-by: Kevin Wolf
> ---
> block/raw-format.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Max
Hy again,
okay so now we have an easy way out just in case.
But I still want to build an DLL and/or a shared library for integration into
the tool. I want the tool to be platform independent and I was already able to
build qemu-img as cross build with mingw64. Does anybody have experience in
On 22.04.20 17:21, Kevin Wolf wrote:
> If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling
> qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't
> undo any previous preallocation, but just adds the zero flag to all
> relevant L2 entries. If an external data file
On Thu, Apr 23, 2020 at 11:20 AM wrote:
> this requires the user of the application to install qemu first right?
> If this is the case then this is unfortunately not an option. The user shall
> not be bothered with installing anything else then the tool.
Hi Janine,
Please use Reply-All to keep
On 22.04.20 17:21, Kevin Wolf wrote:
> Now that node level interface bdrv_truncate() supports passing request
> flags to the block driver, expose this on the BlockBackend level, too.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Alberto Garcia
> ---
>
On 22.04.20 17:21, Kevin Wolf wrote:
> Now that block drivers can support flags for .bdrv_co_truncate, expose
> the parameter in the node level interfaces bdrv_co_truncate() and
> bdrv_truncate().
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: Alberto
On 22.04.20 17:21, Kevin Wolf wrote:
> This adds a new BdrvRequestFlags parameter to the .bdrv_co_truncate()
> driver callbacks, and a supported_truncate_flags field in
> BlockDriverState that allows drivers to advertise support for request
> flags in the context of truncate.
>
> For now, we
65 matches
Mail list logo
