> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Wednesday, September 20, 2023 6:12 PM
> And Parav same goes for you - can you summarize Zhu Lingshan's position? Below is my summary about Zhu Lingshan's position: One line summary of his position in my view: 0. Use inband device migration only, use mediation, mediation is secure, but AQ is not secure. Details of his position in my view: 1. Device migration must be done through VF itself by suspending specific vqs and the VF device both. 2. When device migration is done using #1, it must be done using mediation approach in hypervisor. 3. When migration is done using inband mediation it is more secure than AQ approach. (as opposed to AQ of the owner device who enables/disables SR-IOV). 4. AQ is not secure. But, 5. AQ and admin commands can be built on top of his proposal #1, even if AQ is less secure. Opposing statements... 6. Dirty page tracking and inflight descriptors tracking to be done in his v1. but he does not want to review such coverage in [1]. 8. Since his series does not cover any device context migration and does not talk anything about it, I deduce that he plans to use cvq for setting ups RSS and other fields using inband CVQ of the VF. This further limit the solution to only net device, ignoring rest of the other 20+ device types, where all may not have the CVQ. 9. trapping and emulation of following objects: AQ, CVQ, virtio config space, PCI FLR flow in hypervisor is secure, but when if AQ of the PF do far small work of it, AQ is not secure. 10. Any traps proposed in #9 mostly do not work with future TDISP as TDISP do not bifurcate the device, so ignore them for now to promote inband migration. 11. He do not show interest in collaboration (even after requesting few times) to see if we can produce common commands that may work for both passthrough (without mediation) and using mediation for nested case. 12. Some how register access on single physical card for the PFs and VFs gives better QoS guarantee than virtqueue as registers can scale infinitely no matter how many VFs or for multiple VQs because it is per VF. [1] https://lore.kernel.org/virtio-comment/20230909142911.524407-7-pa...@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
