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

[Jason Wang <jasowang@redhat.com>]

å 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?)

Thanks


> 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.