Messages in this thread | | | Date | Fri, 4 Jun 2021 09:30:54 -0300 | From | Jason Gunthorpe <> | Subject | Re: [RFC] /dev/ioasid uAPI proposal |
| |
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
| |