On 06/05/2024 13:36, Markus Armbruster wrote:
External email: Use caution opening links or attachments
Avihai Horon <avih...@nvidia.com> writes:
On 06/05/2024 7:52, Markus Armbruster wrote:
Avihai Horon <avih...@nvidia.com> writes:
On 01/05/2024 14:50, Joao Martins wrote:
On 30/04/2024 06:16, Avihai Horon wrote:
Add a new QAPI event for VFIO device migration state change. This event
will be emitted when a VFIO device changes its migration state, for
example, during migration or when stopping/starting the guest.
This event can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
Signed-off-by: Avihai Horon <avih...@nvidia.com>
[...]
diff --git a/qapi/vfio.json b/qapi/vfio.json
new file mode 100644
index 0000000000..a38f26bccd
--- /dev/null
+++ b/qapi/vfio.json
@@ -0,0 +1,61 @@
+# -*- Mode: Python -*-
+# vim: filetype=python
+#
+
+##
+# = VFIO devices
+##
+
+##
+# @VFIODeviceMigState:
+#
+# An enumeration of the VFIO device migration states.
+#
+# @stop: The device is stopped.
+#
+# @running: The device is running.
+#
+# @stop-copy: The device is stopped and its internal state is available
+# for reading.
+#
+# @resuming: The device is stopped and its internal state is available
+# for writing.
+#
+# @running-p2p: The device is running in the P2P quiescent state.
+#
+# @pre-copy: The device is running, tracking its internal state and its
+# internal state is available for reading.
+#
+# @pre-copy-p2p: The device is running in the P2P quiescent state,
+# tracking its internal state and its internal state is available
+# for reading.
+#
+# Since: 9.1
+##
+{ 'enum': 'VFIODeviceMigState',
+ 'data': [ 'stop', 'running', 'stop-copy', 'resuming', 'running-p2p',
+ 'pre-copy', 'pre-copy-p2p' ],
+ 'prefix': 'QAPI_VFIO_DEVICE_MIG_STATE' }
Without 'prefix', you get VFIO_DEVICE_MIG_STATE_STOP and so forth. Why
do you need a QAPI_ prefix?
VFIO uAPI already defines enum vfio_device_mig_state and its values
VFIO_DEVICE_STATE_STOP, VFIO_DEVICE_STATE_RUNNING, etc.
I wanted to emphasize these are QAPI entities.
I see.
+
Considering MIG can also be interpreted as Multi Instance GPU elsewhere
unrelated to this shouldn't we be explicit here? i.e.
VFIO_DEVICE_MIGRATION_STATE
... to avoid ambiguiosity.
I used mig to avoid long names, but I don't mind changing it to migration if
that's clearer.
Thanks.
We generally avoid abbreviations in QAPI/QMP.
The event that reports general migration state change is called
MIGRATION, and its data type MigrationStatus.
We could call this one VFIO_MIGRATION, and its data type
VfioMigrationStatus.
Sounds good, but how about VFIOMigrationState (I'd like it to relate to
the VFIO state)?
No objection to "State" instead of "Status" then.
On VFIO vs. Vfio: several existing type names start with Vfio.
Ah, yes, I see: BlockdevOptionsVirtioBlkVfioPci, VfioStats,
VfioUserServerProperties.
I will go with the flow then, VfioMigrationState it is.
Thanks.
