On Mon, Jul 07, 2014 at 01:43:03PM +0300, Oded Gabbay wrote:
> As Jerome pointed out, there are a couple of subsystems/drivers who
> don't rely on file descriptors but on the tear-down of mm struct, e.g.
> aio, ksm, uprobes, khugepaged
What you name here is completly different from what HSA offers. AIO,
KSM, uProbes and THP are not drivers or subsystems of their own but
extend existing subsystems. KSM and THP also work in the background and
do not need a fd to setup things (in some cases only new flags to
existing system calls).
What HSA does is offering a new service to userspace applications. This
either requires new system calls or, as currently implemented, a device
file which can be opened to use the services. In this regard it is much
more similar to VFIO or KVM, which also offers a new service and which
use file descriptors as their interface to userspace and tear everything
down when the fd is closed.
> Jerome and I are saying that HMM and HSA, respectively, are additional
> use cases of binding to mm struct. If you don't agree with that, than I
> would like to hear why, but you can't say that no one else in the kernel
> needs notification of mm struct tear-down.
In the first place HSA is a service that allows applications to send
compute jobs to peripheral devices (usually GPUs) and read back the
results. That the peripheral device can access the process address space
is a feature of that service that is handled in the driver.
> As for the reasons why HSA drivers should follow aio,ksm,etc. and not
> other drivers, I will repeat that our ioctls operate on a process
> context and not on a device context. Moreover, the calling process
> actually is sometimes not aware on which device it runs!
KFD can very well hide the fact that there are multiple devices as the
IOMMU drivers usually also hide the details about how many IOMMUs are in
the system.
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
