Re: [Qemu-devel] [PATCH] blockdev: reset werror/rerror on drive_del

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> Il 04/06/2013 18:37, Markus Armbruster ha scritto:
>> I figure the bit that can't be resolved now is letting the user switch
>> off "stop on error" safely before a drive_del.  Even if we had a command
>> for that, there'd still be a window between that command's execution and
>> drive_del's.  Your patch solves the problem by having drive_del switch
>> it off unconditionally.  Oookay, but please document it, because it's
>> not exactly obvious.
>
> It is not obvious, but it is not surprising either when you see it (i.e.
> you won't really be surprised by the errors in the guest and won't need
> to know that, under the hood, rerror has been changed from the value you
> specified).
>
>> Re "the guest gets the ENOMEDIUM error": depends on the device.  I doubt
>> disks can signal "no medium", and even if they could, I doubt device
>> drivers are prepared for it.
>
> SCSI disks can signal whatever they want.  Device drivers will just
> treat it as any other error (sense code) they don't recognize.

My point is: the commit message claims "the guest gets the ENOMEDIUM
error", which isn't really true.  No biggie, of course.

>> Re "this scenario actually happens sometimes during libvirt disk hot
>> unplug, where device_del is followed by drive_del": if I remember
>> correctly, libvirt disk hot unplug runs drive_del right after
>> device_del, opening a window where the guest sees a dead device.  That's
>> asking for trouble, and trouble is known to oblige.
>
> I think it's causing too much trouble though, and Stefan's patch is
> making the trouble evident to the guest.  Surprise removal is a fact of
> life, I don't think it makes sense to stop the machine on surprise
> removal.  It's very different from I/O errors.

I don't disagree with Stefan's patch, or your defense of it.

Except I'm reluctant to not document something non-obvious because "you
don't need to know" when I can document it in less time it would take me
to overcome my resistance to "you don't need to know" arguments ;)

This is drive_add's documentation in hmp-commands.hx:

    Remove host block device.  The result is that guest generated IO is
    no longer submitted against the host device underlying the disk.
    Once a drive has been deleted, the QEMU Block layer returns -EIO
    which results in IO errors in the guest for applications that are
    reading/writing to the device.

Suggest to add:

    These errors are always reported to the guest, regardless of the
    drive's error actions (drive options rerror, werror).

Independently, libvirt needs fixing.