Re: [Qemu-block] [Qemu-devel] [PATCH] cpus: Fix event order on resume of stopped guest

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 03/05/2018 14:17, Markus Armbruster wrote:
>>>> 4. Connect to the QMP socket e.g. like this:
>>>>    $ socat UNIX:/your/qmp/socket 
>>>> READLINE,history=$HOME/.qmp_history,prompt='QMP> '
>>>>
>>>>    Issue QMP command 'qmp_capabilities':
>>>>    QMP> { "execute": "qmp_capabilities" }
>>>>
>>>> 5. Boot the guest.
>>>>
>>>> 6. In the guest, write to the scratch disk, e.g. like this:
>>>>
>>>>    # dd if=/dev/zero of=/dev/vdb count=1
>>>>
>>>>    Do double-check the device specified with of= is actually the
>>>>    scratch device!
>>>>
>>>> 7. Issue QMP command 'cont':
>>>>    QMP> { "execute": "cont" }
>>>>
>>>> After step 6, I get a BLOCK_IO_ERROR event followed by a STOP event.  Good.
>>>>
>>>> After step 7, I get BLOCK_IO_ERROR, then RESUME, then STOP.  Not so
>>>> good; I'd expect RESUME, then BLOCK_IO_ERROR, then STOP.
>>> Do you want to rephrase this in the form of a script for qemu-iotests?
>>>
>>> I suppose the 'dd' line can be replaced by a 'qemu-io' monitor command.
>> Uh, can it?  With qemu-io, the write doesn't stop the guest, because it
>> bypasses the device model, and thus blk_error_action().  I'm not aware
>> of ways to make qemu-iotests write via a device model.  I'm afraid we
>> need a full-fledged qtest.  Better ideas?
>
> Yeah, using virtio-blk-test sounds like a good idea.

Who's familiar with this test?  I'm not sure I can afford digging into
it myself right now...

The other devices supporting error actions are in hw/scsi/scsi-disk.c,
hw/ide/ahci.c and hw/ide/core.c.  Tests with matching names are
virtio-scsi-test.c, ahci-test.c, ide-test.c.