qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virtio-blk broken after system reset


From: Michael Tokarev
Subject: Re: [Qemu-devel] virtio-blk broken after system reset
Date: Sat, 13 Nov 2010 13:01:36 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10

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 <address@hidden> 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.

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.

Speaking of the bios bug, I included the fix to debian qemu-kvm
package quite some time ago (19 Aug 2010), it is included since
0.12.5+dfsg-2 debian release.  This one:

http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=commit;h=5533a3e87fd19f35a580c8178ce59da72708c63a

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]