Am 13.11.2010 11:01, Michael Tokarev wrote: > 13.11.2010 10:51, Jan Kiszka wrote: >> Am 13.11.2010 08:49, Stefan Hajnoczi wrote: >>> On Fri, Nov 12, 2010 at 10:02 PM, Jan Kiszka <jan.kis...@web.de> wrote: >>>> Hi, >>>> >>>> both after hard and guest-initiated reset, something is seriously broken >>>> with virtio block devices. If I reset my Linux guest while still in >>>> grub, the bios will simply fail to read from the disk after the reboot. If >>>> I >>>> reset after Linux touched the device, qemu terminates: >>>> >>>> Breakpoint 1, 0x00007ffff4b945b0 in _exit () from /lib64/libc.so.6 >>>> (gdb) bt >>>> #0 0x00007ffff4b945b0 in _exit () from /lib64/libc.so.6 >>>> #1 0x00007ffff4b2948d in __run_exit_handlers () from /lib64/libc.so.6 >>>> #2 0x00007ffff4b29535 in exit () from /lib64/libc.so.6 >>>> #3 0x0000000000568da3 in virtqueue_num_heads (vq=0x17040e0, idx=0) at >>>> /data/qemu/hw/virtio.c:258 >>>> #4 0x0000000000569511 in virtqueue_pop (vq=0x17040e0, elem=0x17cea58) at >>>> /data/qemu/hw/virtio.c:388 >>>> #5 0x0000000000419e31 in virtio_blk_get_request (s=0x1704010) at >>>> /data/qemu/hw/virtio-blk.c:132 >>>> #6 virtio_blk_handle_output (vdev=0x1704010, vq=<value optimized out>) at >>>> /data/qemu/hw/virtio-blk.c:369 >>>> > [] >> And what about the guest-triggerable qemu exit above? > > There are _lots_ of guest-triggerable qemu exits out there. > > static int virtqueue_num_heads(VirtQueue *vq, unsigned int idx) > { > uint16_t num_heads = vring_avail_idx(vq) - idx; > > /* Check it isn't doing very strange things with descriptor numbers. */ > if (num_heads > vq->vring.num) { > fprintf(stderr, "Guest moved used index from %u to %u", > idx, vring_avail_idx(vq)); > exit(1); > } > > return num_heads; > } > > This is done when guest behaves insanely (or qemu thinks it does). > On a real hw similar behavour most likely will lead to a system > lockup, qemu just exits.
There is also real hw out there that goes into an error state if it's misprogrammed. I think we have to remove all those premature exits. They also prevent handing the device inside the guest to an untrusted driver (relevant once we have IOMMU emulation). > > Why it is trying to print things to stderr is a different > matter, it should be using a proper error-reporting routine, > but this is a different story. Jep. Even worse: the above message is not dumped to the console as the stream isn't flushed on exit. Jan
signature.asc
Description: OpenPGP digital signature