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
