[PATCH v2 2/4] block-backend: process I/O in the current AioContext

Switch blk_aio_*() APIs over to multi-queue by using qemu_get_current_aio_context() instead of blk_get_aio_context(). This change will allow devices to process I/O in multiple IOThreads in the future. I audited existing blk_aio_*() callers: - migration/block.c: blk_mig_lock() protects the data

[PATCH v2 1/4] block: remove AIOCBInfo->get_aio_context()

The synchronous bdrv_aio_cancel() function needs the acb's AioContext so it can call aio_poll() to wait for cancellation. It turns out that all users run under the BQL in the main AioContext, so this callback is not needed. Remove the callback, mark bdrv_aio_cancel() GLOBAL_STATE_CODE just like

[PATCH v2 0/4] block-backend: process I/O in the current AioContext

v2 - Add patch to remove AIOCBInfo->get_aio_context() [Kevin] - Add patch to use qemu_get_current_aio_context() in block-coroutine-wrapper so that the wrappers use the current AioContext instead of bdrv_get_aio_context(). Switch blk_aio_*() APIs over to multi-queue by using

[PATCH v2 3/4] block-backend: process zoned requests in the current AioContext

Process zoned requests in the current thread's AioContext instead of in the BlockBackend's AioContext. There is no need to use the BlockBackend's AioContext thanks to CoMutex bs->wps->colock, which protects zone metadata. Signed-off-by: Stefan Hajnoczi --- block/block-backend.c | 12

[PATCH v2 4/4] block-coroutine-wrapper: use qemu_get_current_aio_context()

Use qemu_get_current_aio_context() in mixed wrappers and coroutine wrappers so that code runs in the caller's AioContext instead of moving to the BlockDriverState's AioContext. This change is necessary for the multi-queue block layer where any thread can call into the block layer. Most wrappers

[PATCH 2/2] io: follow coroutine AioContext in qio_channel_yield()

The ongoing QEMU multi-queue block layer effort makes it possible for multiple threads to process I/O in parallel. The nbd block driver is not compatible with the multi-queue block layer yet because QIOChannel cannot be used easily from coroutines running in multiple threads. This series changes

[PATCH 0/2] io: follow coroutine AioContext in qio_channel_yield()

The ongoing QEMU multi-queue block layer effort makes it possible for multiple threads to process I/O in parallel. The nbd block driver is not compatible with the multi-queue block layer yet because QIOChannel cannot be used easily from coroutines running in multiple threads. This series changes

[PATCH 1/2] io: check there are no qio_channel_yield() coroutines during ->finalize()

Callers must clean up their coroutines before calling object_unref(OBJECT(ioc)) to prevent an fd handler leak. Add an assertion to check this. This patch is preparation for the fd handler changes that follow. Signed-off-by: Stefan Hajnoczi --- io/channel.c | 4 1 file changed, 4

Re: [PATCH v2 0/3] block: align CoR requests to subclusters

On 8/22/23 22:58, John Snow wrote: > On Tue, Aug 22, 2023 at 1:33 PM Andrey Drobyshev > wrote: >> >> On 8/16/23 12:22, Andrey Drobyshev wrote: >>> On 7/31/23 17:51, Andrey Drobyshev wrote: On 7/24/23 16:11, Andrey Drobyshev wrote: > On 7/11/23 20:25, Andrey Drobyshev wrote: >> v1 -->

[PATCH v4 3/3] hw/nvme: add nvme management interface model

From: Klaus Jensen Add the 'nmi-i2c' device that emulates an NVMe Management Interface controller. Initial support is very basic (Read NMI DS, Configuration Get). This is based on previously posted code by Padmakar Kalghatgi, Arun Kumar Agasar and Saurav Kumar. Signed-off-by: Klaus Jensen

[PATCH v4 2/3] hw/i2c: add mctp core

From: Klaus Jensen Add an abstract MCTP over I2C endpoint model. This implements MCTP control message handling as well as handling the actual I2C transport (packetization). Devices are intended to derive from this and implement the class methods. Parts of this implementation is inspired by

[PATCH v4 0/3] hw/{i2c,nvme}: mctp endpoint, nvme management interface model

This adds a generic MCTP endpoint model that other devices may derive from. Also included is a very basic implementation of an NVMe-MI device, supporting only a small subset of the required commands. Since this all relies on i2c target mode, this can currently only be used with an SoC that

[PATCH v4 1/3] hw/i2c: add smbus pec utility function

From: Klaus Jensen Add i2c_smbus_pec() to calculate the SMBus Packet Error Code for a message. Signed-off-by: Klaus Jensen --- hw/i2c/smbus_master.c | 26 ++ include/hw/i2c/smbus_master.h | 2 ++ 2 files changed, 28 insertions(+) diff --git

Re: Lost partition tables on ide-hd + ahci drive

Am 23.08.23 um 10:47 schrieb Fiona Ebner: > Am 17.02.23 um 22:22 schrieb Mike Maslenkin: >> I can not tell anything about dma-reentracy issues, but yes, i would >> start to look at check_cmd() function call sequence. >> The most interesting is why Sector Count = 1. I thought about race >> with IDE

Re: Lost partition tables on ide-hd + ahci drive

Am 17.02.23 um 22:22 schrieb Mike Maslenkin: > I can not tell anything about dma-reentracy issues, but yes, i would > start to look at check_cmd() function call sequence. > The most interesting is why Sector Count = 1. I thought about race > with IDE reset where registers initialized with > value