Re: [PATCH] ide: Cap LBA28 capacity announcement to 2^28-1

2021-10-05 Thread Samuel Thibault
Ping? Samuel Thibault, le mar. 24 août 2021 12:43:44 +0200, a ecrit: > The LBA28 capacity (at offsets 60/61 of identification) is supposed to > express the maximum size supported by LBA28 commands. If the device is > larger than this, we have to cap it to 2^28-1. > > At least NetBSD happens to

Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration

2021-10-05 Thread Michael S. Tsirkin
On Tue, Oct 05, 2021 at 12:10:08PM -0400, Eduardo Habkost wrote: > On Tue, Oct 05, 2021 at 03:01:05PM +0100, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (m...@redhat.com) wrote: > > > On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote: > > > > On Mon, Oct 04, 2021 at 11:11:00AM

Re: [PATCH v7 3/8] qmp: add QMP command x-debug-query-virtio

2021-10-05 Thread Eric Blake
On Tue, Oct 05, 2021 at 12:45:48PM -0400, Jonah Palmer wrote: > From: Laurent Vivier > > This new command lists all the instances of VirtIODevice with > their QOM paths and virtio type/name. > > Signed-off-by: Jonah Palmer > --- > hw/virtio/meson.build | 2 ++ > hw/virtio/virtio-stub.c

Re: [PATCH v7 1/8] virtio: drop name parameter for virtio_init()

2021-10-05 Thread Eric Blake
On Tue, Oct 05, 2021 at 12:45:46PM -0400, Jonah Palmer wrote: > This patch drops the name parameter for the virtio_init function. > > The pair between the numeric device ID and the string device ID > (name) of a virtio device already exists, but not in a way that > let's us map between them.

[RFC PATCH 3/4] hw/scsi/scsi-generic: Use automatic AIO context lock

2021-10-05 Thread Philippe Mathieu-Daudé
Use the automatic AIO context acquire/release in scsi_command_complete(). Signed-off-by: Philippe Mathieu-Daudé --- hw/scsi/scsi-generic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 665baf900e4..08ef623c030

[RFC PATCH 1/4] block/aio: Add automatically released aio_context variants

2021-10-05 Thread Philippe Mathieu-Daudé
Similarly to commit 5626f8c6d46 ("rcu: Add automatically released rcu_read_lock variants"): AIO_CONTEXT_ACQUIRE_GUARD() acquires the aio context and then uses glib's g_auto infrastructure (and thus whatever the compiler's hooks are) to release it on all exits of the block.

[RFC PATCH 4/4] hw/block/virtio-blk: Use automatic AIO context lock

2021-10-05 Thread Philippe Mathieu-Daudé
Use the automatic AIO context acquire/release in virtio_blk_reset(). Signed-off-by: Philippe Mathieu-Daudé --- hw/block/virtio-blk.c | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index

[RFC PATCH 2/4] hw/scsi/scsi-disk: Use automatic AIO context lock

2021-10-05 Thread Philippe Mathieu-Daudé
Use the automatic AIO context acquire/release in scsi_block_realize(). Signed-off-by: Philippe Mathieu-Daudé --- hw/scsi/scsi-disk.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index e8a547dbb7d..fa2d8543718 100644

[RFC PATCH 0/4] aio: AIO_CONTEXT_ACQUIRE_GUARD() macro experiment

2021-10-05 Thread Philippe Mathieu-Daudé
Experiment to use glib g_autoptr/autofree features with AIO context. Since this is a RFC, only few examples are provided. TODO: Document the macros in docs/devel/multiple-iothreads.txt Philippe Mathieu-Daudé (4): block/aio: Add automatically released aio_context variants hw/scsi/scsi-disk:

Re: [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add

2021-10-05 Thread Kevin Wolf
Am 05.10.2021 um 17:52 hat Damien Hedde geschrieben: > > > On 10/5/21 16:37, Kevin Wolf wrote: > > Am 27.09.2021 um 13:39 hat Kevin Wolf geschrieben: > > > Am 27.09.2021 um 13:06 hat Damien Hedde geschrieben: > > > > On 9/24/21 11:04, Kevin Wolf wrote: > > > > > Directly call

[PATCH v7 3/8] qmp: add QMP command x-debug-query-virtio

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier This new command lists all the instances of VirtIODevice with their QOM paths and virtio type/name. Signed-off-by: Jonah Palmer --- hw/virtio/meson.build | 2 ++ hw/virtio/virtio-stub.c| 14 ++ hw/virtio/virtio.c | 27 +++

[PATCH v7 5/8] qmp: decode feature & status bits in virtio-status

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier Display feature names instead of bitmaps for host, guest, and backend for VirtIODevice. Display status names instead of bitmaps for VirtIODevice. Display feature names instead of bitmaps for backend, protocol, acked, and features (hdev->features) for vhost devices. Decode

Re: [RFC PATCH v2 03/25] block/block-backend.c: assertions for block-backend

2021-10-05 Thread Eric Blake
On Tue, Oct 05, 2021 at 10:31:53AM -0400, Emanuele Giuseppe Esposito wrote: > All the global state (GS) API functions will check that > qemu_in_main_thread() returns true. If not, it means > that the safety of BQL cannot be guaranteed, and > they need to be moved to I/O. > > Signed-off-by:

[PATCH v7 8/8] hmp: add virtio commands

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier This patch implements the HMP versions of the virtio QMP commands. Signed-off-by: Jonah Palmer --- docs/system/monitor.rst | 2 + hmp-commands-virtio.hx | 250 ++ hmp-commands.hx | 10 ++ hw/virtio/virtio.c | 355

[PATCH v7 2/8] virtio: add vhost support for virtio devices

2021-10-05 Thread Jonah Palmer
This patch adds a get_vhost() callback function for VirtIODevices that returns the device's corresponding vhost_dev structure if the vhost device is running. This patch also adds a vhost_started flag for VirtIODevices. Previously, a VirtIODevice wouldn't be able to tell if its corresponding vhost

[PATCH 2/2] block/aio_task: assert `max_busy_tasks` is greater than 0

2021-10-05 Thread Stefano Garzarella
All code in block/aio_task.c expects `max_busy_tasks` to always be greater than 0. Assert this condition during the AioTaskPool creation where `max_busy_tasks` is set. Signed-off-by: Stefano Garzarella --- block/aio_task.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/aio_task.c

[PATCH v7 4/8] qmp: add QMP command x-debug-virtio-status

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier This new command shows the status of a VirtIODevice, including its corresponding vhost device status (if active). Next patch will improve output by decoding feature bits, including vhost device's feature bits (backend, protocol, acked, and features). Also will decode status

[PATCH v7 6/8] qmp: add QMP commands for virtio/vhost queue-status

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier These new commands show the internal status of a VirtIODevice's VirtQueue and a vhost device's vhost_virtqueue (if active). Signed-off-by: Jonah Palmer --- hw/virtio/virtio-stub.c | 14 +++ hw/virtio/virtio.c | 103 +++ qapi/virtio.json| 262

[PATCH v7 7/8] qmp: add QMP command x-debug-virtio-queue-element

2021-10-05 Thread Jonah Palmer
From: Laurent Vivier This new command shows the information of a VirtQueue element. Signed-off-by: Jonah Palmer --- hw/virtio/virtio-stub.c | 9 +++ hw/virtio/virtio.c | 154 ++ qapi/virtio.json| 191

[PATCH v7 0/8] hmp,qmp: Add commands to introspect virtio devices

2021-10-05 Thread Jonah Palmer
This series introduces new QMP/HMP commands to dump the status of a virtio device at different levels. [Jonah: Rebasing previous patchset from July (v6). Original patches are from Laurent Vivier from May 2020. Rebase from v6 to v7 includes adding ability to map between the numeric device ID

[PATCH v7 1/8] virtio: drop name parameter for virtio_init()

2021-10-05 Thread Jonah Palmer
This patch drops the name parameter for the virtio_init function. The pair between the numeric device ID and the string device ID (name) of a virtio device already exists, but not in a way that let's us map between them. This patch will let us do this and removes the need for the name parameter

Re: [PATCH 0/2] block: avoid integer overflow of `max-workers` and assert `max_busy_tasks`

2021-10-05 Thread Vladimir Sementsov-Ogievskiy
10/5/21 19:11, Stefano Garzarella wrote: This series contains a patch that avoids an integer overflow of `max-workers` (struct BackupPerf) by adding a check and a patch that asserts this condition where the problem occurs. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2009310

Re: [PATCH 2/2] block/aio_task: assert `max_busy_tasks` is greater than 0

2021-10-05 Thread Vladimir Sementsov-Ogievskiy
10/5/21 19:11, Stefano Garzarella wrote: All code in block/aio_task.c expects `max_busy_tasks` to always be greater than 0. Assert this condition during the AioTaskPool creation where `max_busy_tasks` is set. Signed-off-by: Stefano Garzarella Reviewed-by: Vladimir Sementsov-Ogievskiy --

Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 17:10:40 CEST Stefan Hajnoczi wrote: > On Tue, Oct 05, 2021 at 03:15:26PM +0200, Christian Schoenebeck wrote: > > On Dienstag, 5. Oktober 2021 14:45:56 CEST Stefan Hajnoczi wrote: > > > On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote: > > > >

Re: [PATCH 1/2] block/backup: avoid integer overflow of `max-workers`

2021-10-05 Thread Vladimir Sementsov-Ogievskiy
10/5/21 19:11, Stefano Garzarella wrote: QAPI generates `struct BackupPerf` where `max-workers` value is stored in an `int64_t` variable. But block_copy_async(), and the underlying code, uses an `int` parameter. At the end that variable is used to initialize `max_busy_tasks` in block/aio_task.c

[PATCH 1/2] block/backup: avoid integer overflow of `max-workers`

2021-10-05 Thread Stefano Garzarella
QAPI generates `struct BackupPerf` where `max-workers` value is stored in an `int64_t` variable. But block_copy_async(), and the underlying code, uses an `int` parameter. At the end that variable is used to initialize `max_busy_tasks` in block/aio_task.c causing the following assertion failure if

[PATCH 0/2] block: avoid integer overflow of `max-workers` and assert `max_busy_tasks`

2021-10-05 Thread Stefano Garzarella
This series contains a patch that avoids an integer overflow of `max-workers` (struct BackupPerf) by adding a check and a patch that asserts this condition where the problem occurs. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2009310 Signed-off-by: Stefano Garzarella Stefano Garzarella

Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration

2021-10-05 Thread Eduardo Habkost
On Tue, Oct 05, 2021 at 03:01:05PM +0100, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (m...@redhat.com) wrote: > > On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote: > > > On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote: > > > > On Mon, Oct 04, 2021 at

Re: [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add

2021-10-05 Thread Damien Hedde
On 10/5/21 16:37, Kevin Wolf wrote: Am 27.09.2021 um 13:39 hat Kevin Wolf geschrieben: Am 27.09.2021 um 13:06 hat Damien Hedde geschrieben: On 9/24/21 11:04, Kevin Wolf wrote: Directly call qdev_device_add_from_qdict() for QMP device_add instead of first going through QemuOpts and

Re: [PATCH 12/15] iotests: Disable AQMP logging under non-debug modes

2021-10-05 Thread Hanna Reitz
On 04.10.21 20:32, John Snow wrote: On Mon, Oct 4, 2021 at 6:12 AM Hanna Reitz > wrote: On 18.09.21 04:14, John Snow wrote: > > > On Fri, Sep 17, 2021 at 8:58 PM John Snow mailto:js...@redhat.com> >

Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

2021-10-05 Thread Stefan Hajnoczi
On Tue, Oct 05, 2021 at 03:15:26PM +0200, Christian Schoenebeck wrote: > On Dienstag, 5. Oktober 2021 14:45:56 CEST Stefan Hajnoczi wrote: > > On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote: > > > Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime > > > variable per

Re: [PULL 00/12] jobs: mirror: Handle errors after READY cancel

2021-10-05 Thread Hanna Reitz
On 04.10.21 19:59, Vladimir Sementsov-Ogievskiy wrote: 10/4/21 19:47, Hanna Reitz wrote: On 24.09.21 00:01, Vladimir Sementsov-Ogievskiy wrote: 22.09.2021 22:19, Vladimir Sementsov-Ogievskiy wrote: 22.09.2021 19:05, Richard Henderson wrote: On 9/21/21 3:20 AM, Vladimir Sementsov-Ogievskiy

[RFC PATCH v2 18/25] block/coroutines: I/O API

2021-10-05 Thread Emanuele Giuseppe Esposito
block coroutines functions run in different aiocontext, and are not protected by the BQL. Therefore are I/O. Signed-off-by: Emanuele Giuseppe Esposito --- block/coroutines.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/block/coroutines.h b/block/coroutines.h index

Re: [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add

2021-10-05 Thread Kevin Wolf
Am 27.09.2021 um 13:39 hat Kevin Wolf geschrieben: > Am 27.09.2021 um 13:06 hat Damien Hedde geschrieben: > > On 9/24/21 11:04, Kevin Wolf wrote: > > > Directly call qdev_device_add_from_qdict() for QMP device_add instead of > > > first going through QemuOpts and converting back to QDict. > > > >

[RFC PATCH v2 23/25] block-backend-common.h: split function pointers in BlockDevOps

2021-10-05 Thread Emanuele Giuseppe Esposito
Assertions in the callers of the funciton pointrs are already added by previous patches. Signed-off-by: Emanuele Giuseppe Esposito --- include/sysemu/block-backend-common.h | 42 +++ 1 file changed, 37 insertions(+), 5 deletions(-) diff --git

[RFC PATCH v2 24/25] job.h: split function pointers in JobDriver

2021-10-05 Thread Emanuele Giuseppe Esposito
The job API will be handled separately in another serie. Signed-off-by: Emanuele Giuseppe Esposito --- include/qemu/job.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/include/qemu/job.h b/include/qemu/job.h index 41162ed494..c236c43026 100644 ---

[RFC PATCH v2 21/25] block_int-common.h: split function pointers in BdrvChildClass

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- include/block/block_int-common.h | 65 ++-- 1 file changed, 46 insertions(+), 19 deletions(-) diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h index 184cfab2d6..a6ea824b64 100644 ---

[RFC PATCH v2 20/25] block_int-common.h: assertion in the callers of BlockDriver function pointers

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- block.c | 16 1 file changed, 16 insertions(+) diff --git a/block.c b/block.c index 7d1eb847a4..a921066d4d 100644 --- a/block.c +++ b/block.c @@ -1069,6 +1069,7 @@ int refresh_total_sectors(BlockDriverState *bs, int64_t hint)

[RFC PATCH v2 14/25] assertions for blockdev.h global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- block/block-backend.c | 2 ++ blockdev.c| 12 2 files changed, 14 insertions(+) diff --git a/block/block-backend.c b/block/block-backend.c index 9f09245069..18791c4fdc 100644 --- a/block/block-backend.c +++

[RFC PATCH v2 22/25] block_int-common.h: assertions in the callers of BdrvChildClass function pointers

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- block.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/block.c b/block.c index a921066d4d..e4b3d40094 100644 --- a/block.c +++ b/block.c @@ -1457,6 +1457,7 @@ const BdrvChildClass child_of_bds = { AioContext

[RFC PATCH v2 19/25] block_int-common.h: split function pointers in BlockDriver

2021-10-05 Thread Emanuele Giuseppe Esposito
Similar to the header split, also the function pointers in BlockDriver can be split in I/O and global state. Signed-off-by: Emanuele Giuseppe Esposito --- include/block/block_int-common.h | 472 --- 1 file changed, 251 insertions(+), 221 deletions(-) diff --git

[RFC PATCH v2 17/25] include/block/transactions: global state API + assertions

2021-10-05 Thread Emanuele Giuseppe Esposito
transactions run always under the BQL lock, so they are all in the global state API. Signed-off-by: Emanuele Giuseppe Esposito --- include/qemu/transactions.h | 24 util/transactions.c | 4 2 files changed, 28 insertions(+) diff --git

[RFC PATCH v2 25/25] job.h: assertions in the callers of JobDriver funcion pointers

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- job.c | 9 + 1 file changed, 9 insertions(+) diff --git a/job.c b/job.c index e7a5d28854..62a13b6982 100644 --- a/job.c +++ b/job.c @@ -373,6 +373,8 @@ void job_ref(Job *job) void job_unref(Job *job) { +

[RFC PATCH v2 16/25] block/backup-top.h: global state API + assertions

2021-10-05 Thread Emanuele Giuseppe Esposito
backup-top functions always run under BQL lock. Signed-off-by: Emanuele Giuseppe Esposito --- block/backup-top.c | 2 ++ block/backup-top.h | 11 +++ 2 files changed, 13 insertions(+) diff --git a/block/backup-top.c b/block/backup-top.c index 425e3778be..8b58a909f7 100644 ---

[RFC PATCH v2 13/25] include/systemu/blockdev.h: global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
blockdev functions run always under the BQL lock. Signed-off-by: Emanuele Giuseppe Esposito --- include/sysemu/blockdev.h | 35 ++- 1 file changed, 30 insertions(+), 5 deletions(-) diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h index

[RFC PATCH v2 12/25] assertions for blockob.h global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- blockjob.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/blockjob.c b/blockjob.c index 9878e255c6..3b224136c0 100644 --- a/blockjob.c +++ b/blockjob.c @@ -61,6 +61,7 @@ static bool is_block_job(Job *job) BlockJob

[RFC PATCH v2 15/25] include/block/snapshot: global state API + assertions

2021-10-05 Thread Emanuele Giuseppe Esposito
Snapshots run also under the BQL lock, so they all are in the global state API. The aiocontext lock that they hold is currently an overkill and in future could be removed. Signed-off-by: Emanuele Giuseppe Esposito --- block/snapshot.c | 28

[RFC PATCH v2 11/25] include/block/blockjob.h: global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
blockjob functions run always under the BQL lock. Signed-off-by: Emanuele Giuseppe Esposito --- include/block/blockjob.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/include/block/blockjob.h b/include/block/blockjob.h index d200f33c10..3bf384f8bf 100644 ---

[RFC PATCH v2 07/25] assertions for block_int global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- block.c | 17 + block/backup.c | 1 + block/block-backend.c | 3 +++ block/commit.c | 2 ++ block/dirty-bitmap.c| 2 ++ block/io.c

[RFC PATCH v2 04/25] include/block/block: split header into I/O and global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Similarly to the previous patch, split block.h in block-io.h and block-global-state.h block-common.h contains the structures shared between the two headers, and the functions that can't be categorized as I/O or global state. Assertions are added in the next patch. Signed-off-by: Emanuele

[RFC PATCH v2 10/25] assertions for blockjob_int.h

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- blockjob.c | 4 1 file changed, 4 insertions(+) diff --git a/blockjob.c b/blockjob.c index 4bad1408cb..9878e255c6 100644 --- a/blockjob.c +++ b/blockjob.c @@ -83,6 +83,7 @@ BlockJob *block_job_get(const char *id) void block_job_free(Job

[RFC PATCH v2 08/25] block: introduce assert_bdrv_graph_writable

2021-10-05 Thread Emanuele Giuseppe Esposito
We want to be sure that the functions that write the child and parent list of a bs are either under BQL or drain. If this guarantee holds, then we can read the list also in the I/O APIs. Signed-off-by: Emanuele Giuseppe Esposito --- block.c| 5 + block/io.c

[RFC PATCH v2 06/25] include/block/block_int: split header into I/O and global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Similarly to the previous patch, split block_int.h in block_int-io.h and block_int-global-state.h block_int-common.h contains the structures shared between the two headers, and the functions that can't be categorized as I/O or global state. Assertions are added in the next patch. Signed-off-by:

[RFC PATCH v2 09/25] include/block/blockjob_int.h: split header into I/O and GS API

2021-10-05 Thread Emanuele Giuseppe Esposito
Since the I/O functions are not many, keep a single file. Also split the function pointers in BlockJobDriver. Signed-off-by: Emanuele Giuseppe Esposito --- include/block/blockjob_int.h | 55 1 file changed, 55 insertions(+) diff --git

[RFC PATCH v2 05/25] assertions for block global state API

2021-10-05 Thread Emanuele Giuseppe Esposito
Signed-off-by: Emanuele Giuseppe Esposito --- block.c| 135 +++-- block/commit.c | 2 + block/io.c | 20 blockdev.c | 1 + 4 files changed, 155 insertions(+), 3 deletions(-) diff --git a/block.c b/block.c index

[RFC PATCH v2 01/25] main-loop.h: introduce qemu_in_main_thread()

2021-10-05 Thread Emanuele Giuseppe Esposito
When invoked from the main loop, this function is the same as qemu_mutex_iothread_locked, and returns true if the BQL is held. When invoked from iothreads or tests, it returns true only if the current AioContext is the Main Loop. This essentially just extends qemu_mutex_iothread_locked to work

[RFC PATCH v2 02/25] include/sysemu/block-backend: split header into I/O and global state (GS) API

2021-10-05 Thread Emanuele Giuseppe Esposito
block-backend.h currently contains a mix of functions: some of them run under the BQL and modify the block layer graph, others are instead thread-safe and perform I/O in iothreads. It is not easy to understand which function is part of which group (I/O vs GS), and this patch aims to clarify it.

[RFC PATCH v2 03/25] block/block-backend.c: assertions for block-backend

2021-10-05 Thread Emanuele Giuseppe Esposito
All the global state (GS) API functions will check that qemu_in_main_thread() returns true. If not, it means that the safety of BQL cannot be guaranteed, and they need to be moved to I/O. Signed-off-by: Emanuele Giuseppe Esposito --- block/block-backend.c | 89

[RFC PATCH v2 00/25] block layer: split block APIs in global state and I/O

2021-10-05 Thread Emanuele Giuseppe Esposito
Currently, block layer APIs like block-backend.h contain a mix of functions that are either running in the main loop and under the BQL, or are thread-safe functions and run in iothreads performing I/O. The functions running under BQL also take care of modifying the block graph, by using drain

Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration

2021-10-05 Thread Dr. David Alan Gilbert
* Michael S. Tsirkin (m...@redhat.com) wrote: > On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote: > > On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote: > > > On Mon, Oct 04, 2021 at 06:07:29PM +0300, Denis Plotnikov wrote: > > > > It might be useful for the cases when

Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 14:45:56 CEST Stefan Hajnoczi wrote: > On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote: > > Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime > > variable per virtio user. > > virtio user == virtio device model? Yes > > Reasons: > >

Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

2021-10-05 Thread Stefan Hajnoczi
On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote: > Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime > variable per virtio user. virtio user == virtio device model? > > Reasons: > > (1) VIRTQUEUE_MAX_SIZE should reflect the absolute theoretical > maximum

Re: [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 13:24:36 CEST Michael S. Tsirkin wrote: > On Tue, Oct 05, 2021 at 01:17:59PM +0200, Christian Schoenebeck wrote: > > On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote: > > > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote: > > >

Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 13:19:43 CEST Michael S. Tsirkin wrote: > On Tue, Oct 05, 2021 at 01:10:56PM +0200, Christian Schoenebeck wrote: > > On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote: > > > On 04.10.21 21:38, Christian Schoenebeck wrote: > > > > At the moment the

Re: [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Michael S. Tsirkin
On Tue, Oct 05, 2021 at 01:17:59PM +0200, Christian Schoenebeck wrote: > On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote: > > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote: > > > Raise the maximum possible virtio transfer size to 128M > > > (more

Re: [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote: > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote: > > Raise the maximum possible virtio transfer size to 128M > > (more precisely: 32k * PAGE_SIZE). See previous commit for a > > more detailed explanation

Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Michael S. Tsirkin
On Tue, Oct 05, 2021 at 01:10:56PM +0200, Christian Schoenebeck wrote: > On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote: > > On 04.10.21 21:38, Christian Schoenebeck wrote: > > > At the moment the maximum transfer size with virtio is limited to 4M > > > (1024 * PAGE_SIZE). This

Re: [PATCH 06/11] qdev: Add Error parameter to qdev_set_id()

2021-10-05 Thread Kevin Wolf
Am 27.09.2021 um 12:33 hat Damien Hedde geschrieben: > Hi Kevin, > > I proposed a very similar patch in our rfc series because we needed some of > the cleaning you do here. > https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05679.html > I've added a bit of doc for the function, feel free

Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Christian Schoenebeck
On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote: > On 04.10.21 21:38, Christian Schoenebeck wrote: > > At the moment the maximum transfer size with virtio is limited to 4M > > (1024 * PAGE_SIZE). This series raises this limit to its maximum > > theoretical possible transfer size

Re: [PATCH v1 2/2] migration: add missing qemu_mutex_lock_iothread in migration_completion

2021-10-05 Thread Dr. David Alan Gilbert
* Emanuele Giuseppe Esposito (eespo...@redhat.com) wrote: > qemu_savevm_state_complete_postcopy assumes the iothread lock (BQL) > to be held, but instead it isn't. > > Signed-off-by: Emanuele Giuseppe Esposito Interesting, I think you're right - and I think it's been missing it from the start.

Re: [PATCH V3] block/rbd: implement bdrv_co_block_status

2021-10-05 Thread Peter Lieven
Am 05.10.21 um 10:36 schrieb Ilya Dryomov: On Tue, Oct 5, 2021 at 10:19 AM Peter Lieven wrote: Am 05.10.21 um 09:54 schrieb Ilya Dryomov: On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote: the qemu rbd driver currently lacks support for bdrv_co_block_status. This results mainly in

Re: [PATCH V3] block/rbd: implement bdrv_co_block_status

2021-10-05 Thread Ilya Dryomov
On Tue, Oct 5, 2021 at 10:19 AM Peter Lieven wrote: > > Am 05.10.21 um 09:54 schrieb Ilya Dryomov: > > On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote: > >> the qemu rbd driver currently lacks support for bdrv_co_block_status. > >> This results mainly in incorrect progress during block

Re: [PATCH V3] block/rbd: implement bdrv_co_block_status

2021-10-05 Thread Peter Lieven
Am 05.10.21 um 09:54 schrieb Ilya Dryomov: On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote: the qemu rbd driver currently lacks support for bdrv_co_block_status. This results mainly in incorrect progress during block operations (e.g. qemu-img convert with an rbd image as source). This

[PATCH v1 1/2] migration: block-dirty-bitmap: add missing qemu_mutex_lock_iothread

2021-10-05 Thread Emanuele Giuseppe Esposito
init_dirty_bitmap_migration assumes the iothread lock (BQL) to be held, but instead it isn't. Instead of adding the lock to qemu_savevm_state_setup(), follow the same pattern as the other ->save_setup callbacks and lock+unlock inside dirty_bitmap_save_setup(). Signed-off-by: Emanuele Giuseppe

[PATCH v1 0/2] Migration: fix missing iothread locking

2021-10-05 Thread Emanuele Giuseppe Esposito
Some functions (in this case qemu_savevm_state_complete_postcopy() and init_dirty_bitmap_migration()) assume and document that qemu_mutex_lock_iothread() is hold. This seems to have been forgotten in some places, and this series aims to fix that. Patch 1 was part of my RFC block layer series

[PATCH v1 2/2] migration: add missing qemu_mutex_lock_iothread in migration_completion

2021-10-05 Thread Emanuele Giuseppe Esposito
qemu_savevm_state_complete_postcopy assumes the iothread lock (BQL) to be held, but instead it isn't. Signed-off-by: Emanuele Giuseppe Esposito --- migration/migration.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/migration/migration.c b/migration/migration.c index

Re: [PATCH V3] block/rbd: implement bdrv_co_block_status

2021-10-05 Thread Ilya Dryomov
On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote: > > the qemu rbd driver currently lacks support for bdrv_co_block_status. > This results mainly in incorrect progress during block operations (e.g. > qemu-img convert with an rbd image as source). > > This patch utilizes the rbd_diff_iterate2

Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread David Hildenbrand
On 04.10.21 21:38, Christian Schoenebeck wrote: At the moment the maximum transfer size with virtio is limited to 4M (1024 * PAGE_SIZE). This series raises this limit to its maximum theoretical possible transfer size of 128M (32k pages) according to the virtio specs:

Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

2021-10-05 Thread Greg Kurz
On Mon, 4 Oct 2021 21:38:04 +0200 Christian Schoenebeck wrote: > Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime > variable per virtio user. > > Reasons: > > (1) VIRTQUEUE_MAX_SIZE should reflect the absolute theoretical > maximum queue size possible. Which is actually the

Re: [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Greg Kurz
On Tue, 5 Oct 2021 03:16:07 -0400 "Michael S. Tsirkin" wrote: > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote: > > Raise the maximum possible virtio transfer size to 128M > > (more precisely: 32k * PAGE_SIZE). See previous commit for a > > more detailed explanation for

Re: [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-10-05 Thread Michael S. Tsirkin
On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote: > Raise the maximum possible virtio transfer size to 128M > (more precisely: 32k * PAGE_SIZE). See previous commit for a > more detailed explanation for the reasons of this change. > > For not breaking any virtio user, all

Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration

2021-10-05 Thread Michael S. Tsirkin
On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote: > On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote: > > On Mon, Oct 04, 2021 at 06:07:29PM +0300, Denis Plotnikov wrote: > > > It might be useful for the cases when a slow block layer should be > > > replaced > > >