On 9/22/2023 4:55 AM, Michael S. Tsirkin wrote:
On Thu, Sep 21, 2023 at 04:51:15PM -0300, Jason Gunthorpe wrote:
On Thu, Sep 21, 2023 at 03:17:25PM -0400, Michael S. Tsirkin wrote:
On Thu, Sep 21, 2023 at 03:39:26PM -0300, Jason Gunthorpe wrote:
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)
I'm asking you to do nothing of the kind - I am saying that this code
will have to be duplicated in vdpa,
Why would that be needed?
For the same reason it was developed in the 1st place - presumably
because it adds efficient legacy guest support with the right card?
I get it, you specifically don't need VDPA functionality, but I don't
see why is this universal, or common.
and so I am asking what exactly is missing to just keep it all
there.
VFIO. Seriously, we don't want unnecessary mediation in this path at
all.
But which mediation is necessary is exactly up to the specific use-case.
I have no idea why would you want all of VFIO to e.g. pass access to
random config registers to the guest when it's a virtio device and the
config registers are all nicely listed in the spec. I know nvidia
hardware is so great, it has super robust cards with less security holes
than the vdpa driver, but I very much doubt this is universal for all
virtio offload cards.
I agree with MST.
note I didn't ask you to add iommufd to vdpa though that would be
nice ;)
I did once send someone to look.. It didn't succeed :(
Jason
Pity. Maybe there's some big difficulty blocking this? I'd like to know.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
