On 23.10.26 08:18, Markus Armbruster wrote:
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?
Technically, sure.
Adding an ID is quite ugly, I feel like, which is why I would need your
input in how it would be least intrusive in QAPI.
(Caveat, at this point: I’m afraid I’ll be quite far from my notebook
for around four weeks… Thank you for your help so far :))
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?
0. I found that natural. Any offset value is a valid offset, but a value
of 0 for bytes sounded good to me.
I now anticipate discomfort with this, so I can make @bytes optional,
too, yes.
Hanna
+#
+# @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' } }
