From: Stefano Garzarella <sgarzare@redhat.com>

Until libblkio 1.3.0, virtio-blk drivers had completion eventfd

notifications enabled from the start, but from the next releases

this is no longer the case, so we have to explicitly enable them.

In fact, the libblkio documentation says they could be disabled,

so we should always enable them at the start if we want to be

sure to get completion eventfd notifications:

By default, the driver might not generate completion events for

requests so it is necessary to explicitly enable the completion

file descriptor before use:

void blkioq_set_completion_fd_enabled(struct blkioq *q, bool enable);

I discovered this while trying a development version of libblkio:

the guest kernel hangs during boot, while probing the device.

Fixes: fd66dbd424f5 ("blkio: add libblkio block driver")

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Message-id: 20230725103744.77343-1-sgarzare@redhat.com

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

---

block/blkio.c | 1 +

1 file changed, 1 insertion(+)

diff --git a/block/blkio.c b/block/blkio.c

index XXXXXXX..XXXXXXX 100644

--- a/block/blkio.c

+++ b/block/blkio.c

@@ -XXX,XX +XXX,XX @@ static int blkio_file_open(BlockDriverState *bs, QDict *options, int flags,

QLIST_INIT(&s->bounce_bufs);

s->blkioq = blkio_get_queue(s->blkio, 0);

s->completion_fd = blkioq_get_completion_fd(s->blkioq);

+ blkioq_set_completion_fd_enabled(s->blkioq, true);

blkio_attach_aio_context(bs, bdrv_get_aio_context(bs));

return 0;

--

2.41.0

From: Stefano Garzarella <sgarzare@redhat.com>

qemu_open() in blkio_virtio_blk_common_open() is used to open the

character device (e.g. /dev/vhost-vdpa-0 or /dev/vfio/vfio) or in

the future eventually the unix socket.

In all these cases we cannot open the path in read-only mode,

when the `read-only` option of blockdev is on, because the exchange

of IOCTL commands for example will fail.

In order to open the device read-only, we have to use the `read-only`

property of the libblkio driver as we already do in blkio_file_open().

Fixes: cad2ccc395 ("block/blkio: use qemu_open() to support fd passing for virtio-blk")

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2225439

Reported-by: Qing Wang <qinwang@redhat.com>

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Message-id: 20230726074807.14041-1-sgarzare@redhat.com

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

---

block/blkio.c | 21 ++++++++++++---------

1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/block/blkio.c b/block/blkio.c

index XXXXXXX..XXXXXXX 100644

--- a/block/blkio.c

+++ b/block/blkio.c

@@ -XXX,XX +XXX,XX @@ static int blkio_virtio_blk_common_open(BlockDriverState *bs,

* layer through the "/dev/fdset/N" special path.

*/

if (fd_supported) {

- int open_flags;

-

- if (flags & BDRV_O_RDWR) {

- open_flags = O_RDWR;

- } else {

- open_flags = O_RDONLY;

- }

-

- fd = qemu_open(path, open_flags, errp);

+ /*

+ * `path` can contain the path of a character device

+ * (e.g. /dev/vhost-vdpa-0 or /dev/vfio/vfio) or a unix socket.

+ *

+ * So, we should always open it with O_RDWR flag, also if BDRV_O_RDWR

+ * is not set in the open flags, because the exchange of IOCTL commands

+ * for example will fail.

+ *

+ * In order to open the device read-only, we are using the `read-only`

+ * property of the libblkio driver in blkio_file_open().

+ */

+ fd = qemu_open(path, O_RDWR, errp);

if (fd < 0) {

return -EINVAL;

}

--

2.41.0

From: Sam Li <faithilikerun@gmail.com>

The g_file_get_contents() function returns a g_boolean. If it fails, the

returned value will be 0 instead of -1. Solve the issue by skipping

assigning ret value.

This issue was found by Matthew Rosato using virtio-blk-{pci,ccw} backed

by an NVMe partition e.g. /dev/nvme0n1p1 on s390x.

Signed-off-by: Sam Li <faithilikerun@gmail.com>

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Message-id: 20230727115844.8480-1-faithilikerun@gmail.com

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

---

block/file-posix.c | 6 ++----

1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c

index XXXXXXX..XXXXXXX 100644

--- a/block/file-posix.c

+++ b/block/file-posix.c

@@ -XXX,XX +XXX,XX @@ static int hdev_get_max_hw_transfer(int fd, struct stat *st)

static int get_sysfs_str_val(struct stat *st, const char *attribute,

char **val) {

g_autofree char *sysfspath = NULL;

- int ret;

size_t len;

if (!S_ISBLK(st->st_mode)) {

@@ -XXX,XX +XXX,XX @@ static int get_sysfs_str_val(struct stat *st, const char *attribute,

sysfspath = g_strdup_printf("/sys/dev/block/%u:%u/queue/%s",

major(st->st_rdev), minor(st->st_rdev),

attribute);

- ret = g_file_get_contents(sysfspath, val, &len, NULL);

- if (ret == -1) {

+ if (!g_file_get_contents(sysfspath, val, &len, NULL)) {

return -ENOENT;

}

@@ -XXX,XX +XXX,XX @@ static int get_sysfs_str_val(struct stat *st, const char *attribute,

if (*(p + len - 1) == '\n') {

*(p + len - 1) = '\0';

}

- return ret;

+ return 0;

}

#endif

--

2.41.0

From: Hanna Czenczek <hreitz@redhat.com>

bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,

which bdrv_check_qiov_request() does not guarantee.

bdrv_check_request32() however will guarantee this, and both of

bdrv_pad_request()'s callers (bdrv_co_preadv_part() and

bdrv_co_pwritev_part()) already run it before calling

bdrv_pad_request(). Therefore, bdrv_pad_request() can safely call

bdrv_check_request32() without expecting error, too.

In effect, this patch will not change guest-visible behavior. It is a

clean-up to tighten a condition to match what is guaranteed by our

callers, and which exists purely to show clearly why the subsequent

assertion (`assert(*bytes <= SIZE_MAX)`) is always true.

Note there is a difference between the interfaces of

bdrv_check_qiov_request() and bdrv_check_request32(): The former takes

an errp, the latter does not, so we can no longer just pass

&error_abort. Instead, we need to check the returned value. While we

do expect success (because the callers have already run this function),

an assert(ret == 0) is not much simpler than just to return an error if

it occurs, so let us handle errors by returning them up the stack now.

Reported-by: Peter Maydell <peter.maydell@linaro.org>

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>

Message-id: 20230714085938.202730-1-hreitz@redhat.com

Fixes: 18743311b829cafc1737a5f20bc3248d5f91ee2a

("block: Collapse padded I/O vecs exceeding IOV_MAX")

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

---

block/io.c | 8 ++++++--

1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c

index XXXXXXX..XXXXXXX 100644

--- a/block/io.c

+++ b/block/io.c

@@ -XXX,XX +XXX,XX @@ static int bdrv_pad_request(BlockDriverState *bs,

int sliced_niov;

size_t sliced_head, sliced_tail;

- bdrv_check_qiov_request(*offset, *bytes, *qiov, *qiov_offset, &error_abort);

+ /* Should have been checked by the caller already */

+ ret = bdrv_check_request32(*offset, *bytes, *qiov, *qiov_offset);

+ if (ret < 0) {

+ return ret;

+ }

if (!bdrv_init_padding(bs, *offset, *bytes, write, pad)) {

if (padded) {

@@ -XXX,XX +XXX,XX @@ static int bdrv_pad_request(BlockDriverState *bs,

&sliced_head, &sliced_tail,

&sliced_niov);

- /* Guaranteed by bdrv_check_qiov_request() */

+ /* Guaranteed by bdrv_check_request32() */

assert(*bytes <= SIZE_MAX);

ret = bdrv_create_padded_qiov(bs, pad, sliced_iov, sliced_niov,

sliced_head, *bytes);

--

2.41.0

From: Stefano Garzarella <sgarzare@redhat.com>

qemu_open() fails if called with an unix domain socket in this way:

-blockdev node-name=drive0,driver=virtio-blk-vhost-user,path=vhost-user-blk.sock,cache.direct=on: Could not open 'vhost-user-blk.sock': No such device or address

Since virtio-blk-vhost-user does not support fd passing, let`s always fall back

on using `path` if we fail the fd passing.

Fixes: cad2ccc395 ("block/blkio: use qemu_open() to support fd passing for virtio-blk")

Reported-by: Qing Wang <qinwang@redhat.com>

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>

Message-id: 20230727161020.84213-4-sgarzare@redhat.com

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

---

block/blkio.c | 20 ++++++++++----------

1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/block/blkio.c b/block/blkio.c

index XXXXXXX..XXXXXXX 100644

--- a/block/blkio.c

+++ b/block/blkio.c

@@ -XXX,XX +XXX,XX @@ static int blkio_virtio_blk_connect(BlockDriverState *bs, QDict *options,

* In order to open the device read-only, we are using the `read-only`

* property of the libblkio driver in blkio_file_open().

*/

- fd = qemu_open(path, O_RDWR, errp);

+ fd = qemu_open(path, O_RDWR, NULL);

if (fd < 0) {

- return -EINVAL;

+ fd_supported = false;

+ } else {

+ ret = blkio_set_int(s->blkio, "fd", fd);

+ if (ret < 0) {

+ fd_supported = false;

+ qemu_close(fd);

+ }

}

+ }

- ret = blkio_set_int(s->blkio, "fd", fd);

- if (ret < 0) {

- error_setg_errno(errp, -ret, "failed to set fd: %s",

- blkio_get_error_msg());

- qemu_close(fd);

- return ret;

- }

- } else {

+ if (!fd_supported) {

ret = blkio_set_str(s->blkio, "path", path);

if (ret < 0) {

error_setg_errno(errp, -ret, "failed to set path: %s",

--

2.41.0