qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2.1 1/3] blockjob: Fix recent BLOCK_JOB_READY


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 2.1 1/3] blockjob: Fix recent BLOCK_JOB_READY regression
Date: Wed, 02 Jul 2014 17:03:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 02/07/2014 16:58, Markus Armbruster ha scritto:
Paolo Bonzini <address@hidden> writes:

Il 02/07/2014 08:55, Markus Armbruster ha scritto:
I think this fixes itself automatically if you use
rerror=stop/werror=stop on block jobs.  At least that was part of the
design, whether the implementation gets it right I cannot say without
looking at the code more carefully.
What if an underlying device doesn't support [rw]error=stop?  Not all
do...

Then the "fix" is to add support to the underlying device.  IDE, SCSI
and virtio-blk (plus virtio-scsi via SCSI of course) are covered;

Where "covered" means "device model calls bdrv_error_action() somewhere"
rather than "device model calls bdrv_error_action() exactly when it
should".

Case in point: SCSI calls it when UNMAP fails, but IDE doesn't call it
when TRIM fails.  IDE and virtio-blk call it for I/O beyond the end of
the medium, but SCSI doesn't.

This is of course fixable.  I'm working on it.

                                                                  the
main one that's left out is SD.

Qdevified devices with a qdev_prop_drive: isa-fdc, sysbus-fdc,
SUNW,fdtwo, nand, onenand, cfi.pflash01, cfi.pflash02, spapr-nvram,
scsi-generic, nvme.  SD isn't in this list, because it still hasn't been
qdevified.  There may be more.

I think there is a page with unfinished transition.  Can you add this one?

Paolo




reply via email to

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