Re: [virtio-comment] [PATCH V2 2/2] virtio: introduce STOP status bit

[Jason Wang <jasowang@redhat.com>]

在 2021/7/15 上午12:22, Max Gurtovoy 写道:
>
> On 7/14/2021 6:07 PM, Stefan Hajnoczi wrote:
>>> It requires much more works than the simple virtqueue interface: 
>>> (the main
>>> issues is that the function is not self-contained in a single function)
>>>
>>> 1) how to interact with the existing device status state machine?
>>> 2) how to make it work in a nested environment?
>>> 3) how to migrate the PF?
>>> 4) do we need to allow more control other than just stop/freeze the 
>>> device
>>> in the admin virtqueue? If yes, how to handle the concurrent access 
>>> from PF
>>> and VF?
>>> 5) how it is expected to work with non-PCI virtio device?
>> I guess your device splitting proposal addresses some of these things?
>>
>> Max probably has the most to say about these points.
>>
>> If you want more input I can try to answer too, but I personally am not
>> developing devices that need this right now, so I might not be the best
>> person to propose solutions.
>
> I think we mentioned this in the past and agreed that the only common 
> entity between my solution for virtio VF migration to this proposal is 
> the new admin control queue.
>
> I can prepare some draft for this.
>
> In our solution the PF will manage migration process for it's VFs 
> using the PF admin queue. PF is not migratable.


That limits the use cases.


>
> I don't know who is using nested environments in production so don't 
> know if it worth talking about that.


There should be plenty users for the nested case.


>
> But, if you would like to implement it for testing, no problem. The VF 
> in level n, probably seen as PF in level n+1. So it can manage the 
> migration process for its nested VFs.


The PF dependency makes the design almost impossible to be used in a 
nested environment.


>
> For question 5) what non-PCI devices are interesting in live migration ?
>

Why not? Virtio support transport other than PCI (CCW, MMIO).

Thanks