+ * Vendor driver should decide whether to partition data section and how to
+ * partition the data section. Vendor driver should return data_offset
+ * accordingly.
+ *
+ * Sequence to be followed for _SAVING|_RUNNING device state or pre-copy phase
+ * and for _SAVING device state or stop-and-copy phase:
+ * a. read pending_bytes. If pending_bytes > 0, go through below steps.
+ * b. read data_offset, indicates kernel driver to write data to staging buffer.
+ * Kernel driver should return this read operation only after writing data to
+ * staging buffer is done.
May I know under what condition this data_offset will be changed per
each iteration from a-f ?
Its upto vendor driver, if vendor driver maintains multiple partitions
in data section.
So, do you mean each time before doing b (reading data_offset), step a
(reading pending_bytes) is mandatory, otherwise the vendor driver does
not know which data_offset is?
pending_bytes will only tell bytes remaining to transfer from vendor
driver. On read operation on data_offset, vendor driver should decide
what to send depending on where he is making data available to userspace.
Then, any lock to wrap step a and b to ensure atomic?
With current QEMU implementation, where migration is single thread,
there is not need of lock yet. But when we add multi-threaded support
may be in future then locks will be required in userspace side.
Thanks,
Kirti
