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 V2 2/2] virtio: introduce STOP status bit

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.

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

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.

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

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