virtio-blk: host/guest disk bandwidth discrepancy

Hi, I am seeing a large discrepancy between host and guest disk bandwidth when using virtio-blk. I would love some insight into the best ways to tune virtio-blk for maximum bandwidth. For context, the hypervisor is connecting to - remote NVMe/oF TCP target over a 200 Gbps NIC. On the host I am

virtio-blk: qemu crash after enabling iothreads

Hi, I am experiencing an issue where my qemu virtual machine crashes when: “cat /proc//maps | wc -l” is greater that “cat /proc/sys/vm/max_map_count” By default, the max_map_count is 65536 on my system. I am not confident that raising this limit will resolve the issue as the number of memory

Re: [PULL 00/16] Migration 20230505 patches

/juan.quintela/qemu.git tags/migration-20230505-pull-request for you to fetch changes up to fae4009fb51b12927165667a9c9d6af93d31b1df: qemu-file: Make ram_control_save_page() use accessors for rate_limit (2023-05-05 02:01:59 +0200

Re: [PATCH] migration: for snapshots, hold the BQL during setup callbacks

On Fri, May 05, 2023 at 03:46:52PM +0200, Fiona Ebner wrote: > To fix it, ensure that the BQL is held during setup. To avoid changing > the behavior for migration too, introduce conditionals for the setup > callbacks that need the BQL and only take the lock if it's not already > held. The major

[PATCH] migration: for snapshots, hold the BQL during setup callbacks

In spirit, this is a partial revert of commit 9b09503752 ("migration: run setup callbacks out of big lock"), but only for the snapshot case. For snapshots, the bdrv_writev_vmstate() function is used during setup (in QIOChannelBlock backing the QEMUFile), but not holding the BQL while calling it

[PATCH v1 0/1] Add support for namespace attach/detach during runtime

This is a follow up on a very old thread[1]. My aim is to attach/detatch nvme devices during runtime and test the Linux nvme subsystem in the guest. In order to it working, I had first to add hotplug able PCI bus and the nvme-subsystem. The nvme-subsystem can't be instatiated during runtime so

[PATCH v1 1/1] hw/nvme: Add hotplug handler to nvme bus

Support attaching/detaching namespaces during runtime. Signed-off-by: Daniel Wagner --- hw/nvme/ctrl.c | 13 + 1 file changed, 13 insertions(+) diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index ac24eeb5ed5a..7bddbc644cae 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -8314,6

Re: [PATCH 9/9] qemu-file: Account for rate_limit usage on qemu_fflush()

Daniel P. Berrangé wrote: >> > >> > This has a slight semantic behavioural change. >> >> Yeap. >> >> See the answer to Peter. But three things came to mind: >> >> a - the size of the buffer is small (between 32KB and 256KB depending >> how you count it). So we are going to call

Re: [PATCH v2 04/20] block: Don't call no_coroutine_fns in qmp_block_resize()

Am 04.05.2023 um 13:57 hat Kevin Wolf geschrieben: > This QMP handler runs in a coroutine, so it must use the corresponding > no_co_wrappers instead. > > Signed-off-by: Kevin Wolf > Reviewed-by: Eric Blake > Reviewed-by: Stefan Hajnoczi I just noticed that this actually fixes a reported hang

Question about graph locking preconditions regarding qemu_in_main_thread()

Hi, I noticed that the bdrv_graph_co_rd_lock() and bdrv_graph_co_rd_unlock() functions use qemu_in_main_thread() as a conditional to return early. What high-level requirements ensure that qemu_in_main_thread() will evaluate to the same value during locking and unlocking? This paragraph assumes no

Re: [PATCH 9/9] qemu-file: Account for rate_limit usage on qemu_fflush()

On Thu, May 04, 2023 at 07:22:25PM +0200, Juan Quintela wrote: > Daniel P. Berrangé wrote: > > On Thu, May 04, 2023 at 01:38:41PM +0200, Juan Quintela wrote: > >> That is the moment we know we have transferred something. > >> > >> Signed-off-by: Juan Quintela > >> --- > >>