On 5/23/2022 9:14 PM, Joao Martins wrote:
External email: Use caution opening links or attachments
On 5/12/22 16:43, Avihai Horon wrote:
Replace the current VFIO migration protocol v1 implementation with a new
implementation corresponding to VFIO migration protocol v2.
The main changes are:
- VFIO device state is now represented as a finite state machine instead
of a bitmap.
- Migration interface with kernel is now done using VFIO_DEVICE_FEATURE
ioctl and normal read() and write() instead of the migration region.
- As VFIO migration protocol v2 currently doesn't support the pre-copy
phase of migration, .save_live_pending and .save_live_iterate handlers
plus pre-copy relevant code are removed.
Detailed information about VFIO migration protocol v2 and difference
compared to v1 can be found here [1].
[1]
https://lore.kernel.org/all/[email protected]/
Signed-off-by: Avihai Horon <[email protected]>
---
hw/vfio/common.c | 21 +-
hw/vfio/migration.c | 628 +++++++---------------------------
hw/vfio/trace-events | 9 +-
include/hw/vfio/vfio-common.h | 8 +-
4 files changed, 153 insertions(+), 513 deletions(-)
This looks like a fairly big patch, though more than 70% of it is removing
code. Perhaps you could split it into adding v2 and removing v1 afterwards,
rather
than a single replacement patch? It's just a suggestion anyhow, to hopefully
ease
analysis of the new additions. The removal looks to muddle a tiny bit.
I don't wanna throw you into potentially unnecessary work should maintainers
disagree,
so here's an attempt:
https://github.com/jpemartins/qemu/commits/for-avihai
Ah, nice idea, thanks! I was afraid this patch would be too cluttered.
Alex, do you want me to split this patch in a similar manner as Joao
suggested? and maybe add v1 prefixes to existing functions instead of v2
to new functions?
If you apply your series on top of the same base commit (78ac2eebbab9) you
should be able
to compare both branches.
I haven't found yet any particular flaws in your new logic (but will reply back
if I find
any).
Sure, thanks!
