On Fri, Jun 04, 2021 at 12:44:28PM +0200, Enrico Weigelt, metux IT consult wrote: > On 02.06.21 19:24, Jason Gunthorpe wrote: > > Hi, > > >> If I understand this correctly, /dev/ioasid is a kind of "common > supplier" > >> to other APIs / devices. Why can't the fd be acquired by the > >> consumer APIs (eg. kvm, vfio, etc) ? > > > > /dev/ioasid would be similar to /dev/vfio, and everything already > > deals with exposing /dev/vfio and /dev/vfio/N together > > > > I don't see it as a problem, just more work. > > One of the problems I'm seeing is in container environments: when > passing in an vfio device, we now also need to pass in /dev/ioasid, > thus increasing the complexity in container setup (or orchestration). Containers already needed to do this today. Container orchestration is hard. > And in such scenarios you usually want to pass in one specific device, > not all of the same class, and usually orchestration shall pick the > next free one. > > Can we make sure that a process having full access to /dev/ioasid > while only supposed to have to specific consumer devices, can't do > any harm (eg. influencing other containers that might use a different > consumer device) ? Yes, /dev/ioasid shouldn't do anything unless you have a device to connect it with. In this way it is probably safe to stuff it into every container. > > Having FDs spawn other FDs is pretty ugly, it defeats the "everything > > is a file" model of UNIX. > > Unfortunately, this is already defeated in many other places :( > (I'd even claim that ioctls already break it :p) I think you are reaching a bit :) > It seems your approach also breaks this, since we now need to open two > files in order to talk to one device. It is two devices, thus two files. Jason
