2008-12-04 22:52:44 +03:00
|
|
|
/*
|
|
|
|
* Virtio Block Device
|
|
|
|
*
|
|
|
|
* Copyright IBM, Corp. 2007
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Anthony Liguori <aliguori@us.ibm.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2. See
|
|
|
|
* the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2016-06-29 14:47:03 +03:00
|
|
|
#ifndef QEMU_VIRTIO_BLK_H
|
|
|
|
#define QEMU_VIRTIO_BLK_H
|
2008-12-04 22:52:44 +03:00
|
|
|
|
2015-02-17 00:36:03 +03:00
|
|
|
#include "standard-headers/linux/virtio_blk.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/virtio/virtio.h"
|
|
|
|
#include "hw/block/block.h"
|
2014-03-03 14:30:08 +04:00
|
|
|
#include "sysemu/iothread.h"
|
2014-10-07 15:59:18 +04:00
|
|
|
#include "sysemu/block-backend.h"
|
2022-10-13 21:59:08 +03:00
|
|
|
#include "sysemu/block-ram-registrar.h"
|
2020-09-03 23:43:22 +03:00
|
|
|
#include "qom/object.h"
|
2008-12-04 22:52:44 +03:00
|
|
|
|
2013-04-09 14:04:48 +04:00
|
|
|
#define TYPE_VIRTIO_BLK "virtio-blk-device"
|
2020-09-16 21:25:19 +03:00
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(VirtIOBlock, VIRTIO_BLK)
|
2013-03-18 20:37:22 +04:00
|
|
|
|
2009-04-23 14:58:51 +04:00
|
|
|
/* This is the last element of the write scatter-gather list */
|
2008-12-04 22:52:44 +03:00
|
|
|
struct virtio_blk_inhdr
|
|
|
|
{
|
|
|
|
unsigned char status;
|
|
|
|
};
|
|
|
|
|
2020-08-18 17:33:47 +03:00
|
|
|
#define VIRTIO_BLK_AUTO_NUM_QUEUES UINT16_MAX
|
|
|
|
|
2012-05-16 14:54:05 +04:00
|
|
|
struct VirtIOBlkConf
|
|
|
|
{
|
|
|
|
BlockConf conf;
|
2014-03-03 14:30:08 +04:00
|
|
|
IOThread *iothread;
|
2012-05-16 14:54:05 +04:00
|
|
|
char *serial;
|
2015-02-02 16:52:22 +03:00
|
|
|
uint32_t request_merging;
|
2016-06-21 15:13:10 +03:00
|
|
|
uint16_t num_queues;
|
2017-12-11 18:16:24 +03:00
|
|
|
uint16_t queue_size;
|
2019-12-20 17:09:04 +03:00
|
|
|
bool seg_max_adjust;
|
2021-02-25 03:12:39 +03:00
|
|
|
bool report_discard_granularity;
|
2019-02-21 13:33:10 +03:00
|
|
|
uint32_t max_discard_sectors;
|
|
|
|
uint32_t max_write_zeroes_sectors;
|
2019-11-05 21:22:17 +03:00
|
|
|
bool x_enable_wce_if_config_wce;
|
2012-05-16 14:54:05 +04:00
|
|
|
};
|
|
|
|
|
2013-02-05 20:06:20 +04:00
|
|
|
struct VirtIOBlockDataPlane;
|
|
|
|
|
2014-06-17 10:32:06 +04:00
|
|
|
struct VirtIOBlockReq;
|
2020-09-03 23:43:22 +03:00
|
|
|
struct VirtIOBlock {
|
2013-03-18 20:37:27 +04:00
|
|
|
VirtIODevice parent_obj;
|
2014-10-07 15:59:18 +04:00
|
|
|
BlockBackend *blk;
|
2013-03-18 20:37:18 +04:00
|
|
|
void *rq;
|
|
|
|
QEMUBH *bh;
|
2014-10-07 15:59:17 +04:00
|
|
|
VirtIOBlkConf conf;
|
2013-03-18 20:37:18 +04:00
|
|
|
unsigned short sector_mask;
|
virtio-blk: do not relay a previous driver's WCE configuration to the current
The following sequence happens:
- the SeaBIOS virtio-blk driver does not support the WCE feature, which
causes QEMU to disable writeback caching
- the Linux virtio-blk driver resets the device, finds WCE is available
but writeback caching is disabled; tells block layer to not send cache
flush commands
- the Linux virtio-blk driver sets the DRIVER_OK bit, which causes
writeback caching to be re-enabled, but the Linux virtio-blk driver does
not know of this side effect and cache flushes remain disabled
The bug is at the third step. If the guest does know about CONFIG_WCE,
QEMU should ignore the WCE feature's state. The guest will control the
cache mode solely using configuration space. This change makes Linux
do flushes correctly, but Linux will keep SeaBIOS's writethrough mode.
Hence, whenever the guest is reset, the cache mode of the disk should
be reset to whatever was specified in the "-drive" option. With this
change, the Linux virtio-blk driver finds that writeback caching is
enabled, and tells the block layer to send cache flush commands
appropriately.
Reported-by: Rusty Russell <rusty@au1.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-09-20 19:31:55 +04:00
|
|
|
bool original_wce;
|
2013-03-18 20:37:18 +04:00
|
|
|
VMChangeStateEntry *change;
|
2016-04-06 13:16:23 +03:00
|
|
|
bool dataplane_disabled;
|
virtio-blk: fix "disabled data plane" mode
In disabled mode, virtio-blk dataplane seems to be enabled, but flow
actually goes through the normal virtio path. This patch simplifies a bit
the handling of disabled mode. In disabled mode, virtio_blk_handle_output
might be called even if s->dataplane is not NULL.
This is a bit tricky, because the current check for s->dataplane will
always trigger, causing a continuous stream of calls to
virtio_blk_data_plane_start. Unfortunately, these calls will not
do anything. To fix this, set the "started" flag even in disabled
mode, and skip virtio_blk_data_plane_start if the started flag is true.
The resulting changes also prepare the code for the next patch, were
virtio-blk dataplane will reuse the same virtio_blk_handle_output function
as "regular" virtio-blk.
Because struct VirtIOBlockDataPlane is opaque in virtio-blk.c, we have
to move s->dataplane->started inside struct VirtIOBlock.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-02-14 20:17:08 +03:00
|
|
|
bool dataplane_started;
|
2013-02-05 20:06:20 +04:00
|
|
|
struct VirtIOBlockDataPlane *dataplane;
|
2019-02-21 13:33:06 +03:00
|
|
|
uint64_t host_features;
|
2019-02-21 13:33:09 +03:00
|
|
|
size_t config_size;
|
2022-10-13 21:59:08 +03:00
|
|
|
BlockRAMRegistrar blk_ram_registrar;
|
2020-09-03 23:43:22 +03:00
|
|
|
};
|
2013-03-18 20:37:18 +04:00
|
|
|
|
2014-06-11 08:11:42 +04:00
|
|
|
typedef struct VirtIOBlockReq {
|
2016-01-31 13:28:57 +03:00
|
|
|
VirtQueueElement elem;
|
2015-02-02 16:52:21 +03:00
|
|
|
int64_t sector_num;
|
2014-06-11 08:11:42 +04:00
|
|
|
VirtIOBlock *dev;
|
2016-06-21 15:13:13 +03:00
|
|
|
VirtQueue *vq;
|
2020-09-17 12:44:54 +03:00
|
|
|
IOVDiscardUndo inhdr_undo;
|
|
|
|
IOVDiscardUndo outhdr_undo;
|
2014-06-11 08:11:42 +04:00
|
|
|
struct virtio_blk_inhdr *in;
|
2014-06-11 08:11:48 +04:00
|
|
|
struct virtio_blk_outhdr out;
|
2014-06-11 08:11:42 +04:00
|
|
|
QEMUIOVector qiov;
|
2015-04-02 20:50:44 +03:00
|
|
|
size_t in_len;
|
2014-06-11 08:11:42 +04:00
|
|
|
struct VirtIOBlockReq *next;
|
2015-02-02 16:52:21 +03:00
|
|
|
struct VirtIOBlockReq *mr_next;
|
2014-06-11 08:11:42 +04:00
|
|
|
BlockAcctCookie acct;
|
|
|
|
} VirtIOBlockReq;
|
|
|
|
|
2015-02-02 16:52:21 +03:00
|
|
|
#define VIRTIO_BLK_MAX_MERGE_REQS 32
|
|
|
|
|
|
|
|
typedef struct MultiReqBuffer {
|
|
|
|
VirtIOBlockReq *reqs[VIRTIO_BLK_MAX_MERGE_REQS];
|
|
|
|
unsigned int num_reqs;
|
|
|
|
bool is_write;
|
|
|
|
} MultiReqBuffer;
|
|
|
|
|
2021-12-07 16:23:33 +03:00
|
|
|
void virtio_blk_handle_vq(VirtIOBlock *s, VirtQueue *vq);
|
virtio-blk: On restart, process queued requests in the proper context
On restart, we were scheduling a BH to process queued requests, which
would run before starting up the data plane, leading to those requests
being assigned and started on coroutines on the main context.
This could cause requests to be wrongly processed in parallel from
different threads (the main thread and the iothread managing the data
plane), potentially leading to multiple issues.
For example, stopping and resuming a VM multiple times while the guest
is generating I/O on a virtio_blk device can trigger a crash with a
stack tracing looking like this one:
<------>
Thread 2 (Thread 0x7ff736765700 (LWP 1062503)):
#0 0x00005567a13b99d6 in iov_memset
(iov=0x6563617073206f4e, iov_cnt=1717922848, offset=516096, fillc=0, bytes=7018105756081554803)
at util/iov.c:69
#1 0x00005567a13bab73 in qemu_iovec_memset
(qiov=0x7ff73ec99748, offset=516096, fillc=0, bytes=7018105756081554803) at util/iov.c:530
#2 0x00005567a12f411c in qemu_laio_process_completion (laiocb=0x7ff6512ee6c0) at block/linux-aio.c:86
#3 0x00005567a12f42ff in qemu_laio_process_completions (s=0x7ff7182e8420) at block/linux-aio.c:217
#4 0x00005567a12f480d in ioq_submit (s=0x7ff7182e8420) at block/linux-aio.c:323
#5 0x00005567a12f43d9 in qemu_laio_process_completions_and_submit (s=0x7ff7182e8420)
at block/linux-aio.c:236
#6 0x00005567a12f44c2 in qemu_laio_poll_cb (opaque=0x7ff7182e8430) at block/linux-aio.c:267
#7 0x00005567a13aed83 in run_poll_handlers_once (ctx=0x5567a2b58c70, timeout=0x7ff7367645f8)
at util/aio-posix.c:520
#8 0x00005567a13aee9f in run_poll_handlers (ctx=0x5567a2b58c70, max_ns=16000, timeout=0x7ff7367645f8)
at util/aio-posix.c:562
#9 0x00005567a13aefde in try_poll_mode (ctx=0x5567a2b58c70, timeout=0x7ff7367645f8)
at util/aio-posix.c:597
#10 0x00005567a13af115 in aio_poll (ctx=0x5567a2b58c70, blocking=true) at util/aio-posix.c:639
#11 0x00005567a109acca in iothread_run (opaque=0x5567a2b29760) at iothread.c:75
#12 0x00005567a13b2790 in qemu_thread_start (args=0x5567a2b694c0) at util/qemu-thread-posix.c:519
#13 0x00007ff73eedf2de in start_thread () at /lib64/libpthread.so.0
#14 0x00007ff73ec10e83 in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7ff743986f00 (LWP 1062500)):
#0 0x00005567a13b99d6 in iov_memset
(iov=0x6563617073206f4e, iov_cnt=1717922848, offset=516096, fillc=0, bytes=7018105756081554803)
at util/iov.c:69
#1 0x00005567a13bab73 in qemu_iovec_memset
(qiov=0x7ff73ec99748, offset=516096, fillc=0, bytes=7018105756081554803) at util/iov.c:530
#2 0x00005567a12f411c in qemu_laio_process_completion (laiocb=0x7ff6512ee6c0) at block/linux-aio.c:86
#3 0x00005567a12f42ff in qemu_laio_process_completions (s=0x7ff7182e8420) at block/linux-aio.c:217
#4 0x00005567a12f480d in ioq_submit (s=0x7ff7182e8420) at block/linux-aio.c:323
#5 0x00005567a12f4a2f in laio_do_submit (fd=19, laiocb=0x7ff5f4ff9ae0, offset=472363008, type=2)
at block/linux-aio.c:375
#6 0x00005567a12f4af2 in laio_co_submit
(bs=0x5567a2b8c460, s=0x7ff7182e8420, fd=19, offset=472363008, qiov=0x7ff5f4ff9ca0, type=2)
at block/linux-aio.c:394
#7 0x00005567a12f1803 in raw_co_prw
(bs=0x5567a2b8c460, offset=472363008, bytes=20480, qiov=0x7ff5f4ff9ca0, type=2)
at block/file-posix.c:1892
#8 0x00005567a12f1941 in raw_co_pwritev
(bs=0x5567a2b8c460, offset=472363008, bytes=20480, qiov=0x7ff5f4ff9ca0, flags=0)
at block/file-posix.c:1925
#9 0x00005567a12fe3e1 in bdrv_driver_pwritev
(bs=0x5567a2b8c460, offset=472363008, bytes=20480, qiov=0x7ff5f4ff9ca0, qiov_offset=0, flags=0)
at block/io.c:1183
#10 0x00005567a1300340 in bdrv_aligned_pwritev
(child=0x5567a2b5b070, req=0x7ff5f4ff9db0, offset=472363008, bytes=20480, align=512, qiov=0x7ff72c0425b8, qiov_offset=0, flags=0) at block/io.c:1980
#11 0x00005567a1300b29 in bdrv_co_pwritev_part
(child=0x5567a2b5b070, offset=472363008, bytes=20480, qiov=0x7ff72c0425b8, qiov_offset=0, flags=0)
at block/io.c:2137
#12 0x00005567a12baba1 in qcow2_co_pwritev_task
(bs=0x5567a2b92740, file_cluster_offset=472317952, offset=487305216, bytes=20480, qiov=0x7ff72c0425b8, qiov_offset=0, l2meta=0x0) at block/qcow2.c:2444
#13 0x00005567a12bacdb in qcow2_co_pwritev_task_entry (task=0x5567a2b48540) at block/qcow2.c:2475
#14 0x00005567a13167d8 in aio_task_co (opaque=0x5567a2b48540) at block/aio_task.c:45
#15 0x00005567a13cf00c in coroutine_trampoline (i0=738245600, i1=32759) at util/coroutine-ucontext.c:115
#16 0x00007ff73eb622e0 in __start_context () at /lib64/libc.so.6
#17 0x00007ff6626f1350 in ()
#18 0x0000000000000000 in ()
<------>
This is also known to cause crashes with this message (assertion
failed):
aio_co_schedule: Co-routine was already scheduled in 'aio_co_schedule'
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1812765
Signed-off-by: Sergio Lopez <slp@redhat.com>
Message-Id: <20200603093240.40489-3-slp@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-06-03 12:32:40 +03:00
|
|
|
void virtio_blk_process_queued_requests(VirtIOBlock *s, bool is_bh);
|
2016-04-06 13:16:26 +03:00
|
|
|
|
2008-12-04 22:52:44 +03:00
|
|
|
#endif
|