Re: [virtio-comment] Live Migration of Virtio Virtual Function

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Aug 19, 2021 at 10:44:46AM +0800, Jason Wang wrote:
> > 
> > The PF device will have an option to quiesce/freeze the VF device.
> 
> 
> Is such design a must? If no, why not simply introduce those functions in
> the VF?

Many IOMMUs only support protections at the function level.
Thus we need ability to have one device (e.g. a PF)
to control migration of another (e.g. a VF).
This is because allowing VF to access hypervisor memory used for
migration is not a good idea. 
For IOMMUs that support subfunctions, these "devices" could be
subfunctions.

The only alternative is to keep things in device memory which
does not need an IOMMU.
I guess we'd end up with something like a VQ in device memory which might
be tricky from multiple points of view, but yes, this could be
useful and people did ask for such a capability in the past.

> If yes, what's the reason for making virtio different (e.g VCPU live
> migration is not designed like that)?

I think the main difference is we need PF's help for memory
tracking for pre-copy migration anyway. Might as well integrate
the rest of state in the same channel.

Another answer is that CPUs trivially switch between
functions by switching the active page tables. For PCI DMA
it is all much trickier sine the page tables can be separate
from the device, and assumed to be mostly static.
So if you want to create something like the VMCS then
again you either need some help from another device or
put it in device memory.


-- 
MST