Re: [PULL for-9.0 0/1] Block patches

On Thu, 21 Mar 2024 at 17:23, Stefan Hajnoczi wrote: > > The following changes since commit fea445e8fe9acea4f775a832815ee22bdf2b0222: > > Merge tag 'pull-maintainer-final-for-real-this-time-200324-1' of > https://gitlab.com/stsquad/qemu into staging (2024-03-21 10:31:56 +) > > are

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_IN_ORDER support

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > The goal of these patches is to add support to a variety of virtio and > vhost devices for the VIRTIO_F_IN_ORDER transport feature. This feature > indicates that all buffers are used by the device in the same order in > which they were made

Re: [RFC 8/8] virtio: Add VIRTIO_F_IN_ORDER property definition

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Extend the virtio device property definitions to include the > VIRTIO_F_IN_ORDER feature. > > The default state of this feature is disabled, allowing it to be > explicitly enabled where it's supported. > Acked-by: Eugenio Pérez Thanks! >

Re: [RFC 7/8] vhost/vhost-user: Add VIRTIO_F_IN_ORDER to vhost feature bits

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Add support for the VIRTIO_F_IN_ORDER feature across a variety of vhost > devices. > > The inclusion of VIRTIO_F_IN_ORDER in the feature bits arrays for these > devices ensures that the backend is capable of offering and providing > support

Re: [RFC 4/8] virtio: Implement in-order handling for virtio devices

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Implements in-order handling for most virtio devices using the > VIRTIO_F_IN_ORDER transport feature, specifically those who call > virtqueue_push to push their used elements onto the used ring. > > The logic behind this implementation is as

[PATCH v3 1/4] block/io: accept NULL qiov in bdrv_pad_request

From: Stefan Reiter Some operations, e.g. block-stream, perform reads while discarding the results (only copy-on-read matters). In this case, they will pass NULL as the target QEMUIOVector, which will however trip bdrv_pad_request, since it wants to extend its passed vector. In particular, this

[PATCH v3 4/4] iotests: add test for stream job with an unaligned prefetch read

Previously, bdrv_pad_request() could not deal with a NULL qiov when a read needed to be aligned. During prefetch, a stream job will pass a NULL qiov. Add a test case to cover this scenario. By accident, also covers a previous race during shutdown, where block graph changes during iteration in

[PATCH v3 0/4] fix two edge cases related to stream block jobs

Changes in v3: * Also deal with edge case in bdrv_next_cleanup(). Haven't run into an actual issue there, but at least the caller in migration/block.c uses bdrv_nb_sectors() which, while not a coroutine wrapper itself (it's written manually), may call

[PATCH v3 2/4] block-backend: fix edge case in bdrv_next() where BDS associated to BB changes

The old_bs variable in bdrv_next() is currently determined by looking at the old block backend. However, if the block graph changes before the next bdrv_next() call, it might be that the associated BDS is not the same that was referenced previously. In that case, the wrong BDS is unreferenced,

[PATCH v3 3/4] block-backend: fix edge case in bdrv_next_cleanup() where BDS associated to BB changes

Same rationale as for commit "block-backend: fix edge case in bdrv_next() where BDS associated to BB changes". The block graph might change between the bdrv_next() call and the bdrv_next_cleanup() call, so it could be that the associated BDS is not the same that was referenced previously anymore.

Re: [RFC 1/8] virtio: Define InOrderVQElement

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Define the InOrderVQElement structure for the VIRTIO_F_IN_ORDER > transport feature implementation. > > The InOrderVQElement structure is used to encapsulate out-of-order > VirtQueueElement data that was processed by the host. This data >