Hanna Czenczek <[email protected]> writes:
> On 20.10.26 08:55, Markus Armbruster wrote:
>> Hanna Czenczek <[email protected]> writes:
>>
>>> This event is emitted when an operation completes, for which a
>>> BLOCK_IO_DELAY event has previously been emitted.
>>>
>>> Signed-off-by: Hanna Czenczek <[email protected]>
>>> ---
>>> qapi/block.json | 33 +++++++++++++++++++++++++++++++++
>>> 1 file changed, 33 insertions(+)
>>>
>>> diff --git a/qapi/block.json b/qapi/block.json
>>> index 5f9f5c28050..38f293dd32d 100644
>>> --- a/qapi/block.json
>>> +++ b/qapi/block.json
>>> @@ -660,6 +660,9 @@
>>> # Note that delays deliberately incurred by throttling do count
>>> # towards the operation duration.
>>> #
>>> +# This event will only be emitted once per request and action. When
>>> +# the operation does finish, a `BLOCK_IO_DONE` event is emitted.
>>
>> I think the first sentence answers a question I had on the previous
>> patch. Move it there?
>
> Sure.
>
>>> +#
>>> # @qom-path: path to the block device object in the QOM tree
>>> #
>>> # @operation: I/O operation
>>> @@ -686,3 +689,33 @@
>>> 'action': 'BlockErrorAction',
>>> '*offset': 'uint64',
>>> 'bytes': 'uint64' } }
>>> +
>>> +##
>>> +# @BLOCK_IO_DONE:
>>> +#
>>> +# Emitted on completion for disk operations that previously emitted a
>>> +# `BLOCK_IO_DELAY` event.
>>
>> Can we have multiple operations in flight that previously emitted
>> BLOCK_IO_DELAY?
>>
>> If yes, might a management application need to connect the BLOCK_IO_DONE
>> back to the BLOCK_IO_DELAY?
>>
>> If yes, how could it do that?
>
> Well, the combination of device, operation, offset, bytes.
>
> Do you think there should be an ID like a u64 counter per BlockBackend?
I'm not overly particular on how exactly the connection can be made. If
the quadruple you suggested always suffices, that's good enough for me.
Documentation should point it out, though.
Can multiple operations with the same (device, operation, offset, bytes)
be in flight?
>> Please use the revised syntax for introductions:
>>
>> ##
>> # @BLOCK_IO_DONE: Emitted on completion for disk operations that
>> # previously emitted a `BLOCK_IO_DELAY` event.
>
> Sure.
>
>>> +#
>>> +# @qom-path: path to the block device object in the QOM tree
>>> +#
>>> +# @operation: I/O operation
>>> +#
>>> +# @latency-ns: Full duration of the operation (in nanoseconds)
>>> +#
>>> +# @offset: Request offset in the guest disk (in bytes), if available
>>
>> Out of curiosity: when could @offset be unavailable?
>
> For flushes.
Uh, what's @bytes then?
>>> +#
>>> +# @bytes: Request length
>>> +#
>>> +# @failed: If true, this request failed for any reason. If false, the
>>
>> Suggest "for some reason".
>
> Sure!
>
> Hanna
>
>>> +# request succeeded.
>>> +#
>>> +# Since: 11.2
>>> +##
>>> +{ 'event': 'BLOCK_IO_DONE',
>>> + 'data': {
>>> + 'qom-path': 'str',
>>> + 'operation': 'IoAccountingOperation',
>>> + 'latency-ns': 'uint64',
>>> + '*offset': 'uint64',
>>> + 'bytes': 'uint64',
>>> + 'failed': 'bool' } }
