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).
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) ?
Note that we don't have device namespaces yet (device isolation still
has to be done w/ complicated bpf magic). I'm already working on that,
but even "simple" things like loopdev allocation turns out to be not
entirely easy.
> 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)
It seems your approach also breaks this, since we now need to open two
files in order to talk to one device.
By the way: my idea does keep the "everything's a file" concept - we
just have a file that allows opening "sub-files". Well, it would be
better if devices could also have directory semantics.
--mtx
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
