[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
On 9/20/2023 9:41 PM, Parav Pandit wrote:
Not exactly, my series implements basic facilities for live migration, admin vq solution can reuse them for sure. admin vq solution can work for some use cases, but for others, you still need to resolveFrom: Michael S. Tsirkin <mst@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.
the issues we talked before.
for fundamentals of virtualization, it is trap and emulate, I think Jason have told you many times.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).
VF owns it and the hypervisor owns the VF, so no side channel.
4. AQ is not secure. But,
so many times discussions....
The security leaks and attacking surface are introduced by AQ, not the basic facilities,5. AQ and admin commands can be built on top of his proposal #1, even if AQ is less secure. Opposing statements...
Will be done in V2, and they are still config space solution, with help of the hypervisor.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.
Any difference from current vhost solution?
for cvq, you should read Eugenio's patcheset, it is secure. For others, we have discussed for many times, no need to repeat.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.
TDISP devices can not be migrated for now, and the TDISP spec make clear examples of attacking models, your admin vq LM on the PF exactly match the model.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.
Sorry I have to repeat this again, this is the last time.
as repeated for many times, we are implementing basic facilities, and you can reuse the basic facilities for live migration in admin vq design, do you want to cooperate?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.
that is per-device facilities.
[1] 20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead">https://lore.kernel.org/virtio-comment/20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]