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. > > 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. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
