[PATCH 0/5] QEMU VFIO live migration
Zhao Yan
yan.y.zhao at intel.com
Tue Mar 12 02:57:47 UTC 2019
hi Alex
thanks for your reply.
So, if we choose migration data to be userspace opaque, do you think below
sequence is the right behavior for vendor driver to follow:
1. initially LOGGING state is not set. If userspace calls GET_BUFFER to
vendor driver, vendor driver should reject and return 0.
2. then LOGGING state is set, if userspace calls GET_BUFFER to vendor
driver,
a. vendor driver shoud first query a whole snapshot of device memory
(let's use this term to represent device's standalone memory for now),
b. vendor driver returns a chunk of data just queried to userspace,
while recording current pos in data.
c. vendor driver finds all data just queried is finished transmitting to
userspace, and queries only dirty data in device memory now.
d. vendor driver returns a chunk of data just quered (this time is dirty
data )to userspace while recording current pos in data
e. if all data is transmited to usespace and still GET_BUFFERs come from
userspace, vendor driver starts another round of dirty data query.
3. if LOGGING state is unset then, and userpace calls GET_BUFFER to vendor
driver,
a. if vendor driver finds there's previously untransmitted data, returns
them until all transmitted.
b. vendor driver then queries dirty data again and transmits them.
c. at last, vendor driver queris device config data (which has to be
queried at last and sent once) and transmits them.
for the 1 bullet, if LOGGING state is firstly set and migration aborts
then, vendor driver has to be able to detect that condition. so seemingly,
vendor driver has to know more qemu's migration state, like migration
called and failed. Do you think that's acceptable?
Thanks
Yan
More information about the intel-gvt-dev
mailing list