Re: [Qemu-block] [PATCH] gluster: fix .bdrv_reopen_prepare when backing file is a JSON object

On 12.07.19 12:46, Stefano Garzarella wrote: > When the backing_file is specified as a JSON object, the > qemu_gluster_reopen_prepare() fails with this message: > invalid URI json:{"server.0.host": ...} > > In this case, we should call qemu_gluster_init() using the QDict > 'state->options'

Re: [Qemu-block] [PATCH] doc: Preallocation does not require writing zeroes

On 12.07.19 12:27, Stefano Garzarella wrote: > On Thu, Jul 11, 2019 at 03:29:35PM +0200, Max Reitz wrote: >> When preallocating an encrypted qcow2 image, it just lets the protocol >> driver write data and then does not mark the clusters as zero. >> Therefore, reading this image will yield

[Qemu-block] [PATCH 3/7] block: Use blk_truncate_for_formatting()

Signed-off-by: Max Reitz --- block/parallels.c | 2 +- block/qcow.c | 2 +- block/qcow2.c | 2 +- block/qed.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/block/parallels.c b/block/parallels.c index 00fae125d1..a17b2d92f2 100644 --- a/block/parallels.c

[Qemu-block] [PATCH 6/7] iscsi: Drop iscsi_co_create_opts()

The generic fallback implementation effectively does the same. Signed-off-by: Max Reitz --- block/iscsi.c | 56 --- 1 file changed, 56 deletions(-) diff --git a/block/iscsi.c b/block/iscsi.c index 267f160bf6..0e5729d335 100644 --- a/block/iscsi.c

[Qemu-block] [PATCH 5/7] file-posix: Drop hdev_co_create_opts()

The generic fallback implementation effectively does the same. Signed-off-by: Max Reitz --- block/file-posix.c | 67 -- 1 file changed, 67 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index 4479cc7ab4..65bd6d 100644 ---

[Qemu-block] [PATCH 7/7] iotests: Add test for image creation fallback

Signed-off-by: Max Reitz --- tests/qemu-iotests/259 | 61 ++ tests/qemu-iotests/259.out | 14 + tests/qemu-iotests/group | 1 + 3 files changed, 76 insertions(+) create mode 100755 tests/qemu-iotests/259 create mode 100644

[Qemu-block] [PATCH 4/7] block: Generic file creation fallback

If a protocol driver does not support image creation, we can see whether maybe the file exists already. If so, just truncating it will be sufficient. Signed-off-by: Max Reitz --- block.c | 83 - 1 file changed, 71 insertions(+), 12

[Qemu-block] [PATCH 1/7] block/nbd: Fix hang in .bdrv_close()

When nbd_close() is called from a coroutine, the connection_co never gets to run, and thus nbd_teardown_connection() hangs. This is because aio_co_enter() only puts the connection_co into the main coroutine's wake-up queue, so this main coroutine needs to yield and wait for connection_co to

[Qemu-block] [PATCH 0/7] block: Generic file creation fallback

Hi, Kevin commented on my RFC, so I got what an RFC wants, and he didn’t object to the creation fallback part. So I suppose I can go down that route at least. (Which was actually the more important part of the series.) So as in the RFC, this series adds a fallback path for creating files (on

[Qemu-block] [PATCH 2/7] block: Add blk_truncate_for_formatting()

Signed-off-by: Max Reitz --- include/sysemu/block-backend.h | 12 block/block-backend.c | 54 ++ 2 files changed, 66 insertions(+) diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h index 733c4957eb..cd9ec8bf52 100644

Re: [Qemu-block] [Qemu-devel] [PATCH-for-4.1 v4 2/5] hw/block/pflash_cfi01: Use the correct READ_ARRAY value

On 7/12/19 5:15 PM, Peter Maydell wrote: > On Thu, 11 Jul 2019 at 16:58, Philippe Mathieu-Daudé > wrote: >> >> In the "Read Array Flowchart" the command has a value of 0xFF. >> >> In the document [*] the "Read Array Flowchart", the READ_ARRAY >> command has a value of 0xff. >> >> Use the correct

Re: [Qemu-block] [PATCH] Fix Guest VM crash due to iSCSI Sense Key error

On 7/11/19 8:24 AM, Stefan Hajnoczi wrote: > On Sun, Jul 07, 2019 at 07:55:03PM -0700, shaju.abra...@nutanix.com wrote: > > Reviewed-by: Stefan Hajnoczi > > CCing John Snow, IDE maintainer. > > You can use scripts/get_maintainer.pl -f hw/ide/core.c to find out who > to send patches to. > >

Re: [Qemu-block] [PULL 0/2] Block layer patches

On Fri, 12 Jul 2019 at 14:53, Kevin Wolf wrote: > > The following changes since commit a2a9d4adabe340617a24eb73a8b2a116d28a6b38: > > Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190712' > into staging (2019-07-12 11:06:48 +0100) > > are available

Re: [Qemu-block] [Qemu-devel] [PATCH-for-4.1 v4 2/5] hw/block/pflash_cfi01: Use the correct READ_ARRAY value

On Thu, 11 Jul 2019 at 16:58, Philippe Mathieu-Daudé wrote: > > In the "Read Array Flowchart" the command has a value of 0xFF. > > In the document [*] the "Read Array Flowchart", the READ_ARRAY > command has a value of 0xff. > > Use the correct value in the pflash model. > > There is no change of

Re: [Qemu-block] [Qemu-devel] [PATCH v3] LUKS: support preallocation

Patchew URL: https://patchew.org/QEMU/20190711150940.17483-1-mlevi...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 20190711150940.17483-1-mlevi...@redhat.com Type: series Subject: [Qemu-devel] [PATCH v3] LUKS:

[Qemu-block] [PULL 2/2] file-posix: Use max transfer length/segment count only for SCSI passthrough

From: Maxim Levitsky Regular kernel block devices (/dev/sda*, /dev/nvme*, etc) don't have max segment size/max segment count hardware requirements exposed to the userspace, but rather the kernel block layer takes care to split the incoming requests that violate these requirements. Allowing the

[Qemu-block] [PULL 1/2] iotests: Update 082 expected output

From: Eric Blake A recent tweak to the '-o help' output for qemu-img needs to be reflected into the iotests expected outputs. Fixes: f7077c98 Reported-by: Kevin Wolf Signed-off-by: Eric Blake Reviewed-by: John Snow Signed-off-by: Kevin Wolf --- tests/qemu-iotests/082.out | 54

[Qemu-block] [PULL 0/2] Block layer patches

The following changes since commit a2a9d4adabe340617a24eb73a8b2a116d28a6b38: Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190712' into staging (2019-07-12 11:06:48 +0100) are available in the Git repository at: git://repo.or.cz/qemu/kevin.git tags/for-upstream for you

Re: [Qemu-block] [RFC 2/5] block: Generic truncation fallback

On 12.07.19 13:48, Max Reitz wrote: > On 12.07.19 13:17, Kevin Wolf wrote: >> Am 12.07.2019 um 12:58 hat Max Reitz geschrieben: >>> On 12.07.19 11:49, Kevin Wolf wrote: Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > If a protocol driver does not support truncation, we call fall back

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

Am 12.07.2019 um 13:44 hat Max Reitz geschrieben: > On 12.07.19 13:23, Kevin Wolf wrote: > > Am 12.07.2019 um 13:09 hat Max Reitz geschrieben: > >> On 12.07.19 13:01, Kevin Wolf wrote: > >>> Am 12.07.2019 um 12:47 hat Max Reitz geschrieben: > On 12.07.19 11:24, Kevin Wolf wrote: > > Am

Re: [Qemu-block] [RFC 2/5] block: Generic truncation fallback

On 12.07.19 13:17, Kevin Wolf wrote: > Am 12.07.2019 um 12:58 hat Max Reitz geschrieben: >> On 12.07.19 11:49, Kevin Wolf wrote: >>> Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: If a protocol driver does not support truncation, we call fall back to effectively not doing anything if

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

On 12.07.19 13:23, Kevin Wolf wrote: > Am 12.07.2019 um 13:09 hat Max Reitz geschrieben: >> On 12.07.19 13:01, Kevin Wolf wrote: >>> Am 12.07.2019 um 12:47 hat Max Reitz geschrieben: On 12.07.19 11:24, Kevin Wolf wrote: > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: >> When

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

Am 12.07.2019 um 13:09 hat Max Reitz geschrieben: > On 12.07.19 13:01, Kevin Wolf wrote: > > Am 12.07.2019 um 12:47 hat Max Reitz geschrieben: > >> On 12.07.19 11:24, Kevin Wolf wrote: > >>> Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > When nbd_close() is called from a coroutine, the

Re: [Qemu-block] [RFC 2/5] block: Generic truncation fallback

Am 12.07.2019 um 12:58 hat Max Reitz geschrieben: > On 12.07.19 11:49, Kevin Wolf wrote: > > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > >> If a protocol driver does not support truncation, we call fall back to > >> effectively not doing anything if the new size is less than the actual >

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

On 12.07.19 13:01, Kevin Wolf wrote: > Am 12.07.2019 um 12:47 hat Max Reitz geschrieben: >> On 12.07.19 11:24, Kevin Wolf wrote: >>> Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: When nbd_close() is called from a coroutine, the connection_co never gets to run, and thus

Re: [Qemu-block] [RFC 3/5] block: Fall back to fallback truncate function

On 12.07.19 12:04, Kevin Wolf wrote: > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: >> file-posix does not need to basically duplicate our fallback truncate >> implementation; and sheepdog can fall back to it for "shrinking" files. >> >> Signed-off-by: Max Reitz >> --- >> block/file-posix.c

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

Am 12.07.2019 um 12:47 hat Max Reitz geschrieben: > On 12.07.19 11:24, Kevin Wolf wrote: > > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > >> When nbd_close() is called from a coroutine, the connection_co never > >> gets to run, and thus nbd_teardown_connection() hangs. > >> > >> This is

Re: [Qemu-block] [RFC 2/5] block: Generic truncation fallback

On 12.07.19 11:49, Kevin Wolf wrote: > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: >> If a protocol driver does not support truncation, we call fall back to >> effectively not doing anything if the new size is less than the actual >> file size. This is what we have been doing for some host

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

On 12.07.19 11:24, Kevin Wolf wrote: > Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: >> When nbd_close() is called from a coroutine, the connection_co never >> gets to run, and thus nbd_teardown_connection() hangs. >> >> This is because aio_co_enter() only puts the connection_co into the main

[Qemu-block] [PATCH] gluster: fix .bdrv_reopen_prepare when backing file is a JSON object

When the backing_file is specified as a JSON object, the qemu_gluster_reopen_prepare() fails with this message: invalid URI json:{"server.0.host": ...} In this case, we should call qemu_gluster_init() using the QDict 'state->options' that contains the parameters already parsed. Buglink:

Re: [Qemu-block] [PATCH] doc: Preallocation does not require writing zeroes

On Thu, Jul 11, 2019 at 03:29:35PM +0200, Max Reitz wrote: > When preallocating an encrypted qcow2 image, it just lets the protocol > driver write data and then does not mark the clusters as zero. > Therefore, reading this image will yield effectively random data. > > As such, we have not

Re: [Qemu-block] [RFC 3/5] block: Fall back to fallback truncate function

Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > file-posix does not need to basically duplicate our fallback truncate > implementation; and sheepdog can fall back to it for "shrinking" files. > > Signed-off-by: Max Reitz > --- > block/file-posix.c | 21 + >

Re: [Qemu-block] [RFC 2/5] block: Generic truncation fallback

Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > If a protocol driver does not support truncation, we call fall back to > effectively not doing anything if the new size is less than the actual > file size. This is what we have been doing for some host device drivers > already. Specifically,

Re: [Qemu-block] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()

Am 11.07.2019 um 21:58 hat Max Reitz geschrieben: > When nbd_close() is called from a coroutine, the connection_co never > gets to run, and thus nbd_teardown_connection() hangs. > > This is because aio_co_enter() only puts the connection_co into the main > coroutine's wake-up queue, so this main

Re: [Qemu-block] [PATCH v2 0/1] Don't obey the kernel block device max transfer len / max segments for raw block devices

Am 04.07.2019 um 14:43 hat Maxim Levitsky geschrieben: > Linux block devices, even in O_DIRECT mode don't have any user visible > limit on transfer size / number of segments, which underlying kernel block > device can have. > The kernel block layer takes care of enforcing these limits by

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/1] Don't obey the kernel block device max transfer len / max segments for raw block devices

> Linux block devices, even in O_DIRECT mode don't have any user visible > limit on transfer size / number of segments, which underlying kernel block > device can have. > The kernel block layer takes care of enforcing these limits by splitting the > bios. > > By limiting the transfer sizes, we

Re: [Qemu-block] [PATCH] Fix Guest VM crash due to iSCSI Sense Key error

On Sun, Jul 07, 2019 at 07:55:03PM -0700, shaju.abra...@nutanix.com wrote: Reviewed-by: Stefan Hajnoczi CCing John Snow, IDE maintainer. You can use scripts/get_maintainer.pl -f hw/ide/core.c to find out who to send patches to. Stefan > From: Shaju Abraham > > During the IDE DMA transfer

Re: [Qemu-block] [PATCH v2 0/1] Don't obey the kernel block device max transfer len / max segments for raw block devices

On Thu, Jul 04, 2019 at 03:43:41PM +0300, Maxim Levitsky wrote: > Linux block devices, even in O_DIRECT mode don't have any user visible > limit on transfer size / number of segments, which underlying kernel block > device can have. > The kernel block layer takes care of enforcing these limits by