On 9/22/2023 2:39 AM, Jason Gunthorpe wrote:
On Thu, Sep 21, 2023 at 12:53:04PM -0400, Michael S. Tsirkin wrote:
vdpa is not vfio, I don't know how you can suggest vdpa is a
replacement for a vfio driver. They are completely different
things.
Each side has its own strengths, and vfio especially is accelerating
in its capability in way that vpda is not. eg if an iommufd conversion
had been done by now for vdpa I might be more sympathetic.
Yea, I agree iommufd is a big problem with vdpa right now. Cindy was
sick and I didn't know and kept assuming she's working on this. I don't
think it's a huge amount of work though. I'll take a look.
Is there anything else though? Do tell.
Confidential compute will never work with VDPA's approach.
I don't understand why vDPA can not and will never support Confidential
computing?
Do you see any blockers?
There are a bunch of things that I think are important for virtio
that are completely out of scope for vfio, such as migrating
cross-vendor.
VFIO supports migration, if you want to have cross-vendor migration
then make a standard that describes the VFIO migration data format for
virtio devices.
What is the huge amount of work am I asking to do?
You are asking us to invest in the complexity of VDPA through out
(keep it working, keep it secure, invest time in deploying and
debugging in the field)
When it doesn't provide *ANY* value to the solution.
The starting point is a completely working vfio PCI function and the
end goal is to put that function into a VM. That is VFIO, not VDPA.
VPDA is fine for what it does, but it is not a reasonable replacement
for VFIO.
Jason
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
