[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] drive_del vs. device_del: what should come first?
|
From: |
Heinz Graalfs |
|
Subject: |
Re: [Qemu-devel] drive_del vs. device_del: what should come first? |
|
Date: |
Thu, 03 Apr 2014 17:20:57 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 02/04/14 19:40, Markus Armbruster wrote:
Heinz Graalfs <address@hidden> writes:
On 01/04/14 17:48, Markus Armbruster wrote:
Heinz Graalfs <address@hidden> writes:
Hi Kevin,
doing a
virsh detach-device ...
ends up in the following QEMU monitor commands:
1. device_del ...
2. drive_del ...
qmp_device_del() performs the device unplug path.
In case of a block device do_drive_del() tries to
prevent further IO against the host device.
However, bdrv_find() during drive_del() results in
an error, because the device is already gone. Due to
this error all the bdrv_xxx calls to quiesce the block
driver as well as all other processing is skipped.
Is the sequence that libvirt triggers OK?
Shouldn't drive_del be executed first?
No.
OK, I see. The drive is deleted implicitly (release_drive()).
Doing a device_del() requires another drive_add() AND device_add().
Yes. The automatic drive delete on unplug is a wart that will not be
preserved in the new interfaces we're building now.
OK, thanks for the info.
(Doing just a device_add() complains about the missing drive.
A subsequent info qtree lets QEMU abort.)
Really? Got a reproducer for me?
The problem seems to be gone on master. I was on 1.7.0 with the info
qtree problem.
drive_del is nasty. Its purpose is to revoke access to an image even
when the guest refuses to cooperate. To the guest, this looks like
hardware failure.
Deleting a device during active IO is nasty and it should look like a
hardware failure. I would expect lots of errors.
If you drive_del before device_del, even a perfectly well-behaved guest
guest is exposed to a terminally broken device between drive_del and
completion of unplug.
The early drive_del() would mean that no further IO would be
possible.
A polite way to describe the effect of drive_del on the guest.
drive_del makes all attempts at actual I/O error out without any
forewarning whatsoever. If you do that to your guest, and something
breaks, you get to keep the pieces. Even if you "only" do it for a
short period of time.
Always try a device_del first, and only if that does not complete within
reasonable time, and you absolutely must revoke access to the image,
then whack it over the head with drive_del.
What is this reasonable time?
Depends on how heavily loaded host and guest are. Suggest to measure
with a suitably thrashing guest, then shift left to taste.
On 390 we experience problems (QEMU abort) when asynch block IO
completes and the virtqueues are already gone. I suppose the
bdrv_drain_all() in bdrv_close() is a little late. I don't see such
problems with an early bdrv_drain_all() (drive_del) and an unplug
(device_del) afterwards.
Sounds like a bug. Got a reproducer?
Here I don't have a reproducer either. Just an old stacktrace, that
occurred several times. It definitely depends on the asynch workload
that is running during the device_del. I will try if I can reproduce
the situation
Program received signal SIGFPE, Arithmetic exception.
0x000000008026e48a in virtqueue_fill (vq=0x809bcad0, elem=0x3ffd80013d8,
len=4097, idx=0) at qemu/hw/virtio/virtio.c:259
259 idx = (idx + vring_used_idx(vq)) % vq->vring.num;
(gdb) bt
#0 0x000000008026e48a in virtqueue_fill (vq=0x809bcad0,
elem=0x3ffd80013d8, len=4097, idx=0) at qemu/hw/virtio/virtio.c:259
#1 0x000000008026e68c in virtqueue_push (vq=0x809bcad0,
elem=0x3ffd80013d8, len=4097) at qemu/hw/virtio/virtio.c:283
#2 0x0000000080237962 in virtio_blk_req_complete (req=0x3ffd80013d0,
status=0) at qemu/hw/block/virtio-blk.c:50
#3 0x0000000080237c08 in virtio_blk_rw_complete (opaque=0x3ffd80013d0,
ret=0) at qemu/hw/block/virtio-blk.c:85
#4 0x0000000080032916 in bdrv_co_em_bh (opaque=0x3ffd800da50) at
qemu/block.c:3847
#5 0x000000008000da0c in aio_bh_poll (ctx=0x808f3e00) at qemu/async.c:81
#6 0x000000008000d498 in aio_poll (ctx=0x808f3e00, blocking=true) at
qemu/aio-posix.c:185
#7 0x0000000080126f56 in qemu_aio_wait () at qemu/main-loop.c:485
#8 0x000000008002a134 in bdrv_drain_all () at qemu/block.c:1449
#9 0x0000000080029e64 in bdrv_close (bs=0x809c1680) at qemu/block.c:1378
#10 0x000000008002ac56 in bdrv_delete (bs=0x809c1680) at qemu/block.c:1612
#11 0x000000008008a7fe in drive_uninit (dinfo=0x809aad00) at
qemu/blockdev.c:216
#12 0x000000008008a95c in drive_put_ref (dinfo=0x809aad00) at
qemu/blockdev.c:227
#13 0x000000008008a00e in blockdev_auto_del (bs=0x809c1680) at
qemu/blockdev.c:106
#14 0x00000000800dc004 in release_drive (obj=0x809b4640, name=0x809b5080
"drive", opaque=0x8044d4b8 <virtio_ccw_blk_properties+224>)
at qemu/hw/core/qdev-properties-system.c:90
#15 0x0000000080195dcc in object_property_del_all (obj=0x809b4640) at
qemu/qom/object.c:343
#16 0x0000000080196158 in object_finalize (data=0x809b4640) at
qemu/qom/object.c:397
#17 0x0000000080197322 in object_unref (obj=0x809b4640) at
qemu/qom/object.c:695
#18 0x0000000080195ff6 in object_unparent (obj=0x809b4640) at
qemu/qom/object.c:377
#19 0x00000000800e2bf6 in qdev_free (dev=0x809b4640) at
qemu/hw/core/qdev.c:286
#20 0x00000000802618e4 in virtio_ccw_busdev_unplug (dev=0x809b4640) at
qemu/hw/s390x/virtio-ccw.c:1582
#21 0x00000000800e27ca in qdev_unplug (dev=0x809b4640,
errp=0x3ffff9c9820) at qemu/hw/core/qdev.c:219
#22 0x000000008016cc9c in qmp_device_del (id=0x809c0490 "virtio-disk3",
errp=0x3ffff9c9820) at qemu/qdev-monitor.c:658
#23 0x000000008018da1e in qmp_marshal_input_device_del (mon=0x8090b2f0,
qdict=0x80987cd0, ret=0x3ffff9c9920) at qmp-marshal.c:2998
#24 0x0000000080293a9a in qmp_call_cmd (mon=0x8090b2f0, cmd=0x803824a0
<qmp_cmds+640>, params=0x80987cd0)
at qemu/monitor.c:4501
#25 0x0000000080293d90 in handle_qmp_command (parser=0x8090b378,
tokens=0x8090a4f0) at /scsi/qemu/monitor.c:4567
#26 0x000000008030607c in json_message_process_token (lexer=0x8090b380,
token=0x809a3780, type=JSON_OPERATOR, x=76, y=21)
at qemu/qobject/json-streamer.c:87
#27 0x000000008032b5b6 in json_lexer_feed_char (lexer=0x8090b380, ch=125
'}', flush=false) at qemu/qobject/json-lexer.c:303
#28 0x000000008032b844 in json_lexer_feed (lexer=0x8090b380,
buffer=0x3ffff9c9fa8 "}[B\377\377\234\237\060", size=1)
at qemu/qobject/json-lexer.c:356
#29 0x000000008030622e in json_message_parser_feed (parser=0x8090b378,
buffer=0x3ffff9c9fa8 "}[B\377\377\234\237\060", size=1)
at qemu/qobject/json-streamer.c:110
#30 0x0000000080293eb0 in monitor_control_read (opaque=0x8090b2f0,
buf=0x3ffff9c9fa8 "}[B\377\377\234\237\060", size=1)
at qemu/monitor.c:4588
#31 0x000000008016d3fe in qemu_chr_be_write (s=0x808f4120,
buf=0x3ffff9c9fa8 "}[B\377\377\234\237\060", len=1)
at qemu/qemu-char.c:165
#32 0x0000000080173380 in tcp_chr_read (chan=0x809783d0, cond=G_IO_IN,
opaque=0x808f4120) at qemu/qemu-char.c:2509
#33 0x000003fffd48f05a in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#34 0x0000000080126bb8 in glib_pollfds_poll () at /scsi/qemu/main-loop.c:188
#35 0x0000000080126d16 in os_host_main_loop_wait (timeout=4294967295) at
qemu/main-loop.c:233
#36 0x0000000080126e06 in main_loop_wait (nonblocking=0) at
qemu/main-loop.c:465
#37 0x00000000801eccea in main_loop () at qemu/vl.c:2086
#38 0x00000000801f539c in main (argc=43, argv=0x3ffff9cb938,
envp=0x3ffff9cba98) at qemu/vl.c:4444