On Wed, 22 Sep 2021 09:22:52 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Sep 22, 2021 at 09:23:34AM +0000, Tian, Kevin wrote: > > > > Providing an ioctl to bind to a normal VFIO container or group might > > > allow a reasonable fallback in userspace.. > > > > I didn't get this point though. An error in binding already allows the > > user to fall back to the group path. Why do we need introduce another > > ioctl to explicitly bind to container via the nongroup interface? > > New userspace still needs a fallback path if it hits the 'try and > fail'. Keeping the device FD open and just using a different ioctl to > bind to a container/group FD, which new userspace can then obtain as a > fallback, might be OK. > > Hard to see without going through the qemu parts, so maybe just keep > it in mind If we assume that the container/group/device interface is essentially deprecated once we have iommufd, it doesn't make a lot of sense to me to tack on a container/device interface just so userspace can avoid reverting to the fully legacy interface. But why would we create vfio device interface files at all if they can't work? I'm not really on board with creating a try-and-fail interface for a mechanism that cannot work for a given device. The existence of the device interface should indicate that it's supported. Thanks, Alex
