OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH 1/1] live_migration: initial support for migrating virtio devices

å 2021/7/7 äå8:51, Max Gurtovoy åé:

+This document will describe the needed updates to the virtio
specification for adding live migration support for various
devices. Live migration is one of the most important features of
virtualization and virtio devices are oftenly found in virtual
environments so setting a standard mechanism for this feature will
allow virtio providers to develop compliant devices that will use
standard drivers for that matter.
Is this supposed to happen on the device side? Do drivers need to get
involved, or is it transparent to them?

Guest drivers should be involved.

Hypervisor drivers should have the vfio re-design that we're doing now in parallel.

We'll develop new virtio_vfio_pci driver that will implement the specification.

Well, this sounds like a partial re-invention of my mdev-vDPA approach which has been rejected by the community. The only difference is that it's PCI specific but I don't think it change anything fundamentally. I agree on the hardware design but not the software part.

This software part should be done in the vDPA (via a new parent) instead of VFIO:

1) dedicated to virtio
2) capable for live migration, thanks to the vhost, vhost-vDPA has the uAPI to support live migration, actually the device state synchronization part is ready, what missed in the dirty page tracking, it would be not hard to introduce the bitmap support, migration compatibility support from the hypervisor(Qemu)
3) compatible with the existing virtio software stack
4) management API support
5) container ready
6) MicroVM ready, datapath assignment without PCI in the guest


Anything that blocks you from using the current mlx5 vDPA parent? It's mature for live migration, switch, representors and a lot features that virtio doesn't have. What's the value of using virtio PF in this case? (Do you plan to invent all those features in the spec?)


Like we're doing for mlx5 NIC, the PF will be the communication channel for the migration process.

The virtio pci PF admin queue will be used for that matter. The PF will not be migratable. It will manage the migration process for its VFs.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]