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

[Stefan Hajnoczi]

On Sat, Nov 13, 2010 at 10:09 AM, Jan Kiszka <address@hidden> wrote:
> 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 <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.
>
> 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).

Interesting point about IOMMU.

>> 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.

stderr is normally unbuffered.  Are you running via libvirt?

Stefan