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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 2.1 1/3] blockjob: Fix recent BLOCK_JOB_READY regression
Date: Thu, 03 Jul 2014 09:19:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

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

Do you mean the transition to qdev?

If yes, isn't that covered by "Making all devices QOM objects"?
Sometimes we create new transitions faster than we finish them...



reply via email to

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