Re: [Qemu-block] qemu-img: add seek option to dd

On Fri, Feb 22, 2019 at 03:59:07PM +0100, Max Reitz wrote: > On 20.02.19 06:54, Richard W.M. Jones wrote: > > It seems like it's not easy to write to a place in a qcow2 file using > > qemu-io or qemu-img. For example suppose I want to overwrite blocks > > 100 and 101 with my own data: > > > > $

[Qemu-block] [PATCH v2 2/4] block/dirty-bitmap: add inconsistent status

Even though the status field is deprecated, we still have to support it for a few more releases. Since this is a very new kind of bitmap state, it makes sense for it to have its own status field. Signed-off-by: John Snow --- block/dirty-bitmap.c | 7 ++- qapi/block-core.json | 7 ++- 2

[Qemu-block] [PATCH v2 4/4] block/dirty-bitmaps: implement inconsistent bit

Set the inconsistent bit on load instead of rejecting such bitmaps. There is no way to un-set it; the only option is to delete it. Obvervations: - bitmap loading does not need to update the header for in_use bitmaps. - inconsistent bitmaps don't need to have their data loaded; they're glorified

[Qemu-block] [PATCH v2 1/4] block/dirty-bitmaps: add inconsistent bit

Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap as persistent but potentially inconsistent, i.e. if we find bitmaps on a qcow2 that have been marked as "in use". Signed-off-by: John Snow --- block/dirty-bitmap.c | 19 +++

[Qemu-block] [PATCH v2 0/4] bitmaps: add inconsistent bit

Allow QEMU to read in bitmaps that have the in-use bit set, for the purposes of allowing users to delete those bitmaps. This is chosen in preference to a hard error on load to minimize impact for a non-critical error, but to force the user or management utility to acknowledge that the bitmap is

[Qemu-block] [PATCH v2 3/4] block/dirty-bitmaps: add block_dirty_bitmap_check function

Instead of checking against busy, inconsistent, or read only directly, use a check function with permissions bits that let us streamline the checks without reproducing them in many places. As a side effect, this adds consistency checks to all the QMP interfaces for bitmap manipulation.

[Qemu-block] [PATCH v3 07/10] block/dirty-bitmaps: unify qmp_locked and user_locked calls

These mean the same thing now. Unify them and rename the merged call bdrv_dirty_bitmap_busy to indicate semantically what we are describing, as well as help disambiguate from the various _locked and _unlocked versions of bitmap helpers that refer to mutex locks. Signed-off-by: John Snow ---

[Qemu-block] [PATCH v3 03/10] block/dirty-bitmap: remove set/reset assertions against enabled bit

bdrv_set_dirty_bitmap and bdrv_reset_dirty_bitmap are only used as an internal API by the mirror and migration areas of our code. These calls modify the bitmap, but do so at the behest of QEMU and not the guest. Presently, these bitmaps are always "enabled" anyway, but there's no reason they have

[Qemu-block] [PATCH v3 08/10] block/dirty-bitmaps: move comment block

Simply move the big status enum comment block to above the status function, and document it as being deprecated. The whole confusing block can get deleted in three releases time. Signed-off-by: John Snow --- block/dirty-bitmap.c | 36 +++- 1 file changed, 19

[Qemu-block] [PATCH v3 09/10] blockdev: remove unused paio parameter documentation

This field isn't present anymore. Signed-off-by: John Snow --- blockdev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/blockdev.c b/blockdev.c index 1aaadb6128..cbce44877d 100644 --- a/blockdev.c +++ b/blockdev.c @@ -1255,7 +1255,6 @@ out_aio_context: * @node: The name of the BDS node

[Qemu-block] [PATCH v3 05/10] nbd: change error checking order for bitmaps

Check that the bitmap is not in use prior to it checking if it is not enabled/recording guest writes. The bitmap being busy was likely at the behest of the user, so this error has a greater chance of being understood by the user. Signed-off-by: John Snow --- nbd/server.c | 10 +- 1 file

[Qemu-block] [PATCH v3 00/10] dirty-bitmaps: deprecate @status field

The current internal meanings of "locked", "user_locked", "qmp_locked", "frozen", "enabled", and "disabled" are all a little muddled. Deprecate the @status field in favor of two new booleans that carry very specific meanings. Then, rename and rework some of the internal semantics to help make the

[Qemu-block] [PATCH v3 02/10] block/dirty-bitmaps: rename frozen predicate helper

"Frozen" was a good description a long time ago, but it isn't adequate now. Rename the frozen predicate to has_successor to make the semantics of the predicate more clear to outside callers. In the process, remove some calls to frozen() that no longer semantically make sense. For

[Qemu-block] [PATCH v3 10/10] iotests: add busy/recording bit test to 124

This adds a simple test that ensures the busy bit works for push backups, as well as doubling as bonus test for incremental backups that get interrupted by EIO errors. Recording bit tests are already handled sufficiently by 236. Signed-off-by: John Snow --- tests/qemu-iotests/124 | 110

[Qemu-block] [PATCH v3 06/10] block/dirty-bitmap: explicitly lock bitmaps with successors

Instead of implying a user_locked/busy status, make it explicit. Now, bitmaps in use by migration, NBD or backup operations are all treated the same way with the same code paths. Signed-off-by: John Snow Reviewed-by: Eric Blake --- block/dirty-bitmap.c | 11 ++- 1 file changed, 6

[Qemu-block] [PATCH v3 04/10] block/dirty-bitmap: change semantics of enabled predicate

Currently, the enabled predicate means something like: "the QAPI status of the bitmap is ACTIVE." After this patch, it should mean exclusively: "This bitmap is recording guest writes, and is allowed to do so." In many places, this is how this predicate was already used. Internal usages of the

[Qemu-block] [PATCH v3 01/10] block/dirty-bitmap: add recording and busy properties

The current API allows us to report a single status, which we've defined as: Frozen: has a successor, treated as qmp_locked, may or may not be enabled. Locked: no successor, qmp_locked. may or may not be enabled. Disabled: Not frozen or locked, disabled. Active: Not frozen, locked, or disabled.

Re: [Qemu-block] [ovirt-users] qemu-img info showed iscsi/FC lun size 0

Hi Nir, Thanks for your reply. What about qcow2 format? Is there a choice  to create vm disk with format qcow2 instead of raw? Thanks, Jingjie On 2/21/19 5:46 PM, Nir Soffer wrote: On Thu, Feb 21, 2019, 21:48 wrote: Hi, Based on oVirt 4.3.0,

[Qemu-block] [PULL 4/7] tests.acceptance: adds multi vm capability for acceptance tests

From: Caio Carrara This change adds the possibility to write acceptance tests with multi virtual machine support. It's done keeping the virtual machines objects stored in a test attribute (dictionary). This dictionary shouldn't be accessed directly but through the new method added `get_vm`. This

[Qemu-block] [PULL 6/7] Acceptance tests: use linux-3.6 and set vm memory to 4GiB

From: Li Zhijian QEMU have already supported to load up to 4G initrd if the sepcified memory is enough and XLF_CAN_BE_LOADED_ABOVE_4G is set by guest kernel linux-3.6 kernel shipped by Fedora-18 cannot support xldflags so that it cannot support loading more than 2GiB initrd CC: Wainer dos

[Qemu-block] [PULL 7/7] Acceptance tests: expect boot to extract 2GiB+ initrd with linux-v4.16

From: Li Zhijian XLF_CAN_BE_LOADED_ABOVE_4G is set on vmlinuz shipped by Fedora-28 so that it's allowed to be loaded below 4 GB address. timeout is updated to 5 minutes as well since we need more time to load a large initrd to the guest CC: Wainer dos Santos Moschetta CC: Caio Carrara CC:

[Qemu-block] [PULL 3/7] scripts/qemu.py: log QEMU launch command line

Even when the launch of QEMU succeeds, it's useful to have the command line recorded. Reviewed-by: Caio Carrara Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée Signed-off-by: Cleber Rosa Message-Id: <20190202005610.24048-2-cr...@redhat.com> Signed-off-by: Cleber Rosa ---

[Qemu-block] [PULL 5/7] tests.acceptance: adds simple migration test

From: Caio Carrara This change adds the simplest possible migration test. Beyond the test purpose itself it's also useful to exercise the multi virtual machines capabilities from base avocado qemu test class. Signed-off-by: Cleber Rosa Signed-off-by: Caio Carrara Reviewed-by: Cleber Rosa

[Qemu-block] [PULL 2/7] Introduce a Python module structure

This is a simple move of Python code that wraps common QEMU functionality, and are used by a number of different tests and scripts. By treating that code as a real Python module, we can more easily: * reuse code * have a proper place for the module's own unittests * apply a more consistent

[Qemu-block] [PULL 0/7] Python queue, 2019-02-22

The following changes since commit 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116: Merge remote-tracking branch 'remotes/awilliam/tags/vfio-updates-20190221.0' into staging (2019-02-22 15:48:04 +) are available in the Git repository at: git://github.com/clebergnu/qemu.git

[Qemu-block] [PULL 1/7] Acceptance tests: drop usage of ":avocado: enable"

The Avocado test runner attemps to find its INSTRUMENTED (that is, Python based tests) in a manner that is as safe as possible to the user. Different from plain Python unittest, it won't load or execute test code on an operation such as: $ avocado list tests/acceptance/ Before version 68.0,

Re: [Qemu-block] [PATCH 2/2] qcow2: mark image as corrupt if failing during create

On 19.02.19 13:50, Daniel P. Berrangé wrote: > During creation we write a minimal qcow2 header and then update it with > extra features. If the updating fails for some reason we might still be > left with a valid qcow2 image that will be mistakenly used for I/O. We > cannot delete the image, since

Re: [Qemu-block] [PATCH 1/2] qcow2: fail if encryption opts are provided to non-encrypted image

On 19.02.19 13:50, Daniel P. Berrangé wrote: > If the qcow2 image does not have any encryption method specified in its > header, the user should not be providing any encryption options when > opening it. We already detect this if the user had set "encrypt.format" > but this field is optional so

Re: [Qemu-block] [ovirt-users] qemu-img info showed iscsi/FC lun size 0

On Fri, Feb 22, 2019 at 7:14 PM Nir Soffer wrote: > On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang > wrote: > >> What about qcow2 format? >> > qcow2 reports the real size regardless of the underlying storage, since qcow2 manages the allocations. However the size is reported in qemu-img check in

Re: [Qemu-block] [ovirt-users] qemu-img info showed iscsi/FC lun size 0

On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang wrote: > What about qcow2 format? > > Is there a choice to create vm disk with format qcow2 instead of raw? > Not for LUNs, only for images. The available formats in 4.3 are documented here:

Re: [Qemu-block] [PATCH v2 1/2] iotests: ensure we print nbd server log on error

On Fri, Feb 22, 2019 at 09:54:25AM -0600, Eric Blake wrote: > On 2/22/19 9:16 AM, Daniel P. Berrangé wrote: > > On Fri, Feb 22, 2019 at 04:06:32PM +0100, Max Reitz wrote: > >> On 20.02.19 15:58, Daniel P. Berrangé wrote: > >>> If we abort the iotest early the server.log file might contain useful >

Re: [Qemu-block] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

Am 22.02.2019 um 17:13 hat Max Reitz geschrieben: > On 22.02.19 16:57, Kevin Wolf wrote: > > Am 22.02.2019 um 14:51 hat Max Reitz geschrieben: > >> On 19.02.19 10:17, Kevin Wolf wrote: > >>> Am 19.02.2019 um 01:47 hat Max Reitz geschrieben: > On 31.01.19 18:55, Kevin Wolf wrote: > >

Re: [Qemu-block] [RFC PATCH 10/11] qcow2: Store data file name in the image

On 22.02.19 17:06, Kevin Wolf wrote: > Am 22.02.2019 um 16:43 hat Max Reitz geschrieben: >> On 22.02.19 16:35, Kevin Wolf wrote: >>> Am 22.02.2019 um 15:16 hat Max Reitz geschrieben: On 19.02.19 10:04, Kevin Wolf wrote: > Am 19.02.2019 um 01:18 hat Max Reitz geschrieben: >> On

Re: [Qemu-block] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

On 22.02.19 16:57, Kevin Wolf wrote: > Am 22.02.2019 um 14:51 hat Max Reitz geschrieben: >> On 19.02.19 10:17, Kevin Wolf wrote: >>> Am 19.02.2019 um 01:47 hat Max Reitz geschrieben: On 31.01.19 18:55, Kevin Wolf wrote: > Signed-off-by: Kevin Wolf > --- > qapi/block-core.json |

Re: [Qemu-block] [PATCH v2 1/2] iotests: ensure we print nbd server log on error

On 22.02.19 16:54, Eric Blake wrote: > On 2/22/19 9:16 AM, Daniel P. Berrangé wrote: >> On Fri, Feb 22, 2019 at 04:06:32PM +0100, Max Reitz wrote: >>> On 20.02.19 15:58, Daniel P. Berrangé wrote: If we abort the iotest early the server.log file might contain useful information for

Re: [Qemu-block] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

Am 22.02.2019 um 14:51 hat Max Reitz geschrieben: > On 19.02.19 10:17, Kevin Wolf wrote: > > Am 19.02.2019 um 01:47 hat Max Reitz geschrieben: > >> On 31.01.19 18:55, Kevin Wolf wrote: > >>> Signed-off-by: Kevin Wolf > >>> --- > >>> qapi/block-core.json | 1 + > >>> block/qcow2.c| 6

Re: [Qemu-block] [RFC PATCH 10/11] qcow2: Store data file name in the image

Am 22.02.2019 um 16:43 hat Max Reitz geschrieben: > On 22.02.19 16:35, Kevin Wolf wrote: > > Am 22.02.2019 um 15:16 hat Max Reitz geschrieben: > >> On 19.02.19 10:04, Kevin Wolf wrote: > >>> Am 19.02.2019 um 01:18 hat Max Reitz geschrieben: > On 31.01.19 18:55, Kevin Wolf wrote: > >

Re: [Qemu-block] [PATCH v2 1/2] iotests: ensure we print nbd server log on error

On 2/22/19 9:16 AM, Daniel P. Berrangé wrote: > On Fri, Feb 22, 2019 at 04:06:32PM +0100, Max Reitz wrote: >> On 20.02.19 15:58, Daniel P. Berrangé wrote: >>> If we abort the iotest early the server.log file might contain useful >>> information for diagnosing the problem. Ensure its contents are

Re: [Qemu-block] qemu-img: add seek option to dd

On 2/22/19 8:59 AM, Max Reitz wrote: >> >> Is there anything I'm missing? What is the status of that patch? > > Eric sent another version last year: > > http://lists.nongnu.org/archive/html/qemu-block/2018-08/msg00513.html > > My main issue is that dd should be a frontend to convert, but it

Re: [Qemu-block] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure

Am 22.02.2019 um 15:12 hat Max Reitz geschrieben: > On 19.02.19 09:51, Kevin Wolf wrote: > > Am 19.02.2019 um 00:57 hat Max Reitz geschrieben: > >> On 31.01.19 18:55, Kevin Wolf wrote: > >>> This adds a .bdrv_open option to specify the external data file node. > >>> > >>> Signed-off-by: Kevin Wolf

Re: [Qemu-block] [RFC PATCH 10/11] qcow2: Store data file name in the image

Am 22.02.2019 um 15:16 hat Max Reitz geschrieben: > On 19.02.19 10:04, Kevin Wolf wrote: > > Am 19.02.2019 um 01:18 hat Max Reitz geschrieben: > >> On 31.01.19 18:55, Kevin Wolf wrote: > >>> Rather than requiring that the external data file node is passed > >>> explicitly when creating the qcow2

Re: [Qemu-block] [RFC PATCH 10/11] qcow2: Store data file name in the image

On 22.02.19 16:35, Kevin Wolf wrote: > Am 22.02.2019 um 15:16 hat Max Reitz geschrieben: >> On 19.02.19 10:04, Kevin Wolf wrote: >>> Am 19.02.2019 um 01:18 hat Max Reitz geschrieben: On 31.01.19 18:55, Kevin Wolf wrote: > Rather than requiring that the external data file node is passed

Re: [Qemu-block] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure

On 22.02.19 16:38, Kevin Wolf wrote: > Am 22.02.2019 um 15:12 hat Max Reitz geschrieben: >> On 19.02.19 09:51, Kevin Wolf wrote: >>> Am 19.02.2019 um 00:57 hat Max Reitz geschrieben: On 31.01.19 18:55, Kevin Wolf wrote: > This adds a .bdrv_open option to specify the external data file

Re: [Qemu-block] [Qemu-devel] [PATCH v2] iotests: handle TypeError for Python3 in test 242

On 2/22/19 6:26 AM, Andrey Shinkevich wrote: > The data type for bytes in Python3 differs from the one in Python2. > Those cases should be managed separately. > > v1: > In the first version, the TypeError in Python3 was handled as the > exception. > Discussed in the e-mail thread with the

Re: [Qemu-block] [PATCH v2 1/2] iotests: ensure we print nbd server log on error

On Fri, Feb 22, 2019 at 04:06:32PM +0100, Max Reitz wrote: > On 20.02.19 15:58, Daniel P. Berrangé wrote: > > If we abort the iotest early the server.log file might contain useful > > information for diagnosing the problem. Ensure its contents are > > displayed in this case. > > > > Reviewed-by:

Re: [Qemu-block] [PATCH v2 1/2] iotests: ensure we print nbd server log on error

On 20.02.19 15:58, Daniel P. Berrangé wrote: > If we abort the iotest early the server.log file might contain useful > information for diagnosing the problem. Ensure its contents are > displayed in this case. > > Reviewed-by: Eric Blake > Signed-off-by: Daniel P. Berrangé > --- >

Re: [Qemu-block] qemu-img: add seek option to dd

On 20.02.19 06:54, Richard W.M. Jones wrote: > It seems like it's not easy to write to a place in a qcow2 file using > qemu-io or qemu-img. For example suppose I want to overwrite blocks > 100 and 101 with my own data: > > $ qemu-img dd -f raw -O qcow2 bs=4096 skip=100 count=2 \ >

Re: [Qemu-block] [PATCH v2] iotests: handle TypeError for Python3 in test 242

On 2/22/19 5:26 AM, Andrey Shinkevich wrote: > The data type for bytes in Python3 differs from the one in Python2. > Those cases should be managed separately. > > v1: > In the first version, the TypeError in Python3 was handled as the > exception. > Discussed in the e-mail thread with the Message

Re: [Qemu-block] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure

On 19.02.19 09:51, Kevin Wolf wrote: > Am 19.02.2019 um 00:57 hat Max Reitz geschrieben: >> On 31.01.19 18:55, Kevin Wolf wrote: >>> This adds a .bdrv_open option to specify the external data file node. >>> >>> Signed-off-by: Kevin Wolf >>> --- >>> qapi/block-core.json | 3 ++- >>>

Re: [Qemu-block] [RFC PATCH 10/11] qcow2: Store data file name in the image

On 19.02.19 10:04, Kevin Wolf wrote: > Am 19.02.2019 um 01:18 hat Max Reitz geschrieben: >> On 31.01.19 18:55, Kevin Wolf wrote: >>> Rather than requiring that the external data file node is passed >>> explicitly when creating the qcow2 node, store the filename in the >>> designated header

[Qemu-block] [PULL 24/27] tests/virtio-blk: change assert on data_size in virtio_blk_request()

From: Stefano Garzarella The size of data in the virtio_blk_request must be a multiple of 512 bytes for IN and OUT requests, or a multiple of the size of struct virtio_blk_discard_write_zeroes for DISCARD and WRITE_ZEROES requests. Reviewed-by: Michael S. Tsirkin Reviewed-by: Stefan Hajnoczi

Re: [Qemu-block] [RFC PATCH 06/11] qcow2: Don't assume 0 is an invalid cluster offset

On 19.02.19 09:45, Kevin Wolf wrote: > Am 19.02.2019 um 00:13 hat Max Reitz geschrieben: >> On 31.01.19 18:55, Kevin Wolf wrote: >>> The cluster allocation code uses 0 as an invalid offset that is used in >>> case of errors or as "offset not yet determined". With external data >>> files, a host

[Qemu-block] [PULL 27/27] tests/virtio-blk: add test for DISCARD command

From: Stefano Garzarella If the DISCARD feature is enabled, we try this command in the test_basic(), checking only the status returned by the request. Reviewed-by: Stefan Hajnoczi Signed-off-by: Stefano Garzarella Message-id: 20190221103314.58500-11-sgarz...@redhat.com Message-Id:

[Qemu-block] [PULL 23/27] virtio-blk: add DISCARD and WRITE_ZEROES features

From: Stefano Garzarella This patch adds the support of DISCARD and WRITE_ZEROES commands, that have been introduced in the virtio-blk protocol to have better performance when using SSD backend. We support only one segment per request since multiple segments are not widely used and there are no

[Qemu-block] [PULL 19/27] virtio-blk: add host_features field in VirtIOBlock

From: Stefano Garzarella Since configurable features for virtio-blk are growing, this patch adds host_features field in the struct VirtIOBlock. (as in virtio-net) In this way, we can avoid to add new fields for new properties and we can directly set VIRTIO_BLK_F* flags in the host_features. We

[Qemu-block] [PULL 21/27] virtio-net: make VirtIOFeature usable for other virtio devices

From: Stefano Garzarella In order to use VirtIOFeature also in other virtio devices, we move its declaration and the endof() macro (renamed in virtio_endof()) in virtio.h. We add virtio_feature_get_config_size() function to iterate the array of VirtIOFeature and to return the config size

[Qemu-block] [PULL 20/27] virtio-blk: add "discard" and "write-zeroes" properties

From: Stefano Garzarella In order to avoid migration issues, we enable DISCARD and WRITE_ZEROES features only for machine type >= 4.0 As discussed with Michael S. Tsirkin and Stefan Hajnoczi on the list [1], DISCARD operation should not have security implications (eg. page cache attacks), so we

[Qemu-block] [PULL 16/27] hw/ide: drop iov field from IDEBufferedRequest

From: Vladimir Sementsov-Ogievskiy @iov is used only to initialize @qiov. Let's use new qemu_iovec_init_buf() instead, which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 26/27] tests/virtio-blk: add test for WRITE_ZEROES command

From: Stefano Garzarella If the WRITE_ZEROES feature is enabled, we check this command in the test_basic(). Reviewed-by: Michael S. Tsirkin Reviewed-by: Stefan Hajnoczi Acked-by: Thomas Huth Signed-off-by: Stefano Garzarella Message-id: 20190221103314.58500-10-sgarz...@redhat.com

[Qemu-block] [PULL 17/27] hw/ide: drop iov field from IDEDMA

From: Vladimir Sementsov-Ogievskiy @iov is used only to initialize @qiov. Let's use new qemu_iovec_init_buf() instead, which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 12/27] qemu-img: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 25/27] tests/virtio-blk: add virtio_blk_fix_dwz_hdr() function

From: Stefano Garzarella This function is useful to fix the endianness of struct virtio_blk_discard_write_zeroes headers. Reviewed-by: Stefan Hajnoczi Signed-off-by: Stefano Garzarella Message-id: 20190221103314.58500-9-sgarz...@redhat.com Message-Id:

[Qemu-block] [PULL 18/27] virtio-blk: add acct_failed param to virtio_blk_handle_rw_error()

From: Stefano Garzarella We add acct_failed param in order to use virtio_blk_handle_rw_error() also when is not required to call block_acct_failed(). (eg. a discard operation is failed) Reviewed-by: Michael S. Tsirkin Reviewed-by: Stefan Hajnoczi Signed-off-by: Stefano Garzarella Message-id:

[Qemu-block] [PULL 22/27] virtio-blk: set config size depending on the features enabled

From: Stefano Garzarella Starting from DISABLE and WRITE_ZEROES features, we use an array of VirtIOFeature (as virtio-net) to properly set the config size depending on the features enabled. Reviewed-by: Stefan Hajnoczi Signed-off-by: Stefano Garzarella Message-id:

[Qemu-block] [PULL 14/27] tests/test-bdrv-drain: use QEMU_IOVEC_INIT_BUF

From: Vladimir Sementsov-Ogievskiy Use new QEMU_IOVEC_INIT_BUF() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 15/27] hw/ide: drop iov field from IDEState

From: Vladimir Sementsov-Ogievskiy @iov is used only to initialize @qiov. Let's use new qemu_iovec_init_buf() instead, which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 09/27] block/qcow2: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 10/27] block/qed: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 13/27] migration/block: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 08/27] block/qcow: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 11/27] block/vmdk: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 00/27] Block patches

The following changes since commit fc3dbb90f2eb069801bfb4cfe9cbc83cf9c5f4a9: Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-02-21 13:09:33 +) are available in the Git repository at: git://github.com/stefanha/qemu.git tags/block-pull-request

[Qemu-block] [PULL 03/27] block/block-backend: use QEMU_IOVEC_INIT_BUF

From: Vladimir Sementsov-Ogievskiy Use new QEMU_IOVEC_INIT_BUF() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 01/27] block: enhance QEMUIOVector structure

From: Vladimir Sementsov-Ogievskiy Add a possibility of embedded iovec, for cases when we need only one local iov. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Message-id: 20190218140926.333779-2-vsement...@virtuozzo.com Message-Id:

[Qemu-block] [PULL 07/27] block/parallels: use QEMU_IOVEC_INIT_BUF

From: Vladimir Sementsov-Ogievskiy Use new QEMU_IOVEC_INIT_BUF() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 06/27] block/stream: use QEMU_IOVEC_INIT_BUF

From: Vladimir Sementsov-Ogievskiy Use new QEMU_IOVEC_INIT_BUF() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 05/27] block/commit: use QEMU_IOVEC_INIT_BUF

From: Vladimir Sementsov-Ogievskiy Use new QEMU_IOVEC_INIT_BUF() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 04/27] block/backup: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Message-id:

[Qemu-block] [PULL 02/27] block/io: use qemu_iovec_init_buf

From: Vladimir Sementsov-Ogievskiy Use new qemu_iovec_init_buf() instead of qemu_iovec_init_external( ... , 1), which simplifies the code. While being here, use qemu_try_blockalign0 as well. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi

Re: [Qemu-block] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2

On 19.02.19 10:17, Kevin Wolf wrote: > Am 19.02.2019 um 01:47 hat Max Reitz geschrieben: >> On 31.01.19 18:55, Kevin Wolf wrote: >>> Signed-off-by: Kevin Wolf >>> --- >>> qapi/block-core.json | 1 + >>> block/qcow2.c| 6 +- >>> 2 files changed, 6 insertions(+), 1 deletion(-) >> >>

Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmware

The other day, I described how my attempt to implement Paolo's suggestion to add block properties to the machine ran into difficulties. To recap briefly, creating devices within a machine's .instance_init() crashes. Turns out device_post_init() calls qdev_get_machine(), which calls

[Qemu-block] [PATCH v2] iotests: handle TypeError for Python3 in test 242

The data type for bytes in Python3 differs from the one in Python2. Those cases should be managed separately. v1: In the first version, the TypeError in Python3 was handled as the exception. Discussed in the e-mail thread with the Message ID:

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: implement copy offload (-C) for dd

Am 21.02.2019 um 20:32 hat Sergio Lopez geschrieben: > On Thu, Feb 21, 2019 at 12:08:12PM -0600, Eric Blake wrote: > > On 2/21/19 11:37 AM, Sergio Lopez wrote: > > > This parameter is analogous to convert's "-C", making use of > > > bdrv_co_copy_range(). > > > > The last time I tried to patch

Re: [Qemu-block] [PATCH v6 00/10] virtio-blk: add DISCARD and WRITE_ZEROES features

On Thu, Feb 21, 2019 at 11:33:04AM +0100, Stefano Garzarella wrote: > This series adds the support of DISCARD and WRITE_ZEROES commands > and extends the virtio-blk-test to test these new commands. > > v6: > - fixed patchew failure on patch 8 (do not initialise globals to 0 or NULL) > - added R-b

Re: [Qemu-block] [Qemu-devel] [PATCH] iotests: handle TypeError for Python3 in test 242

On 22/02/2019 03:17, Cleber Rosa wrote: > > > On 2/18/19 4:25 PM, Philippe Mathieu-Daudé wrote: >> On 2/18/19 9:05 PM, Eric Blake wrote: >>> [adding Eduardo for some python 2-vs-3 advice] >> >> And Cleber. >> >>> >>> On 2/18/19 1:59 PM, Andrey Shinkevich wrote: To write one byte to disk,