This is an update of task isolation work that was originally done by Chris Metcalf <cmetcalf@xxxxxxxxxxxx> and maintained by him until November 2017. It is adapted to the current kernel and cleaned up to implement its functionality in a more complete and cleaner manner. Previous version is at https://lore.kernel.org/netdev/04be044c1bcd76b7438b7563edc35383417f12c8.camel@xxxxxxxxxxx/ The last version by Chris Metcalf (now obsolete but may be relevant for comparison and understanding the origin of the changes) is at https://lore.kernel.org/lkml/1509728692-10460-1-git-send-email-cmetcalf@xxxxxxxxxxxx Supported architectures This version includes only architecture-independent code and arm64 support. x86 and arm support, and everything related to virtualization will be re-added later when new kernel entry/exit implementation will be accommodated. Support for other architectures can be added in a somewhat modular manner, however it heavily depends on the details of a kernel entry/exit support on any particular architecture. Development of common entry/exit and conversion to it should simplify that task. For now, this is the version that is currently being developed on arm64. Major changes since v4 The goal was to make isolation-breaking detection as generic as possible, and remove everything related to determining, _why_ isolation was broken. Originally reporting isolation breaking was done with a large number of of hooks in specific code (hardware interrupts, syscalls, IPIs, page faults, etc.), and it was necessary to cover all possible such events to have a reliable notification of a task about its isolation being broken. To avoid such a fragile mechanism, this version relies on mere fact of kernel being entered in isolation mode. As a result, reporting happens later in kernel code, however it covers everything. This means that now there is no specific reporting, in kernel log or elsewhere, about the reasons for breaking isolation. Information about that may be valuable at runtime, so a separate mechanism for generic reporting "why did CPU enter kernel" (with isolation or under other conditions) may be a good thing. That can be done later, however at this point it's important that task isolation does not require it, and such mechanism will not be developed with the limited purpose of supporting isolation alone. General description This is the result of development and maintenance of task isolation functionality that originally started based on task isolation patch v15 and was later updated to include v16. It provided predictable environment for userspace tasks running on arm64 processors alongside with full-featured Linux environment. It is intended to provide reliable interruption-free environment from the point when a userspace task enters isolation and until the moment it leaves isolation or receives a signal intentionally sent to it, and was successfully used for this purpose. While CPU isolation with nohz provides an environment that is close to this requirement, the remaining IPIs and other disturbances keep it from being usable for tasks that require complete predictability of CPU timing. This set of patches only covers the implementation of task isolation, however additional functionality, such as selective TLB flushes, may be implemented to avoid other kinds of disturbances that affect latency and performance of isolated tasks. The userspace support and test program is now at https://github.com/abelits/libtmc . It was originally developed for earlier implementation, so it has some checks that may be redundant now but kept for compatibility. My thanks to Chris Metcalf for design and maintenance of the original task isolation patch, Francis Giraldeau <francis.giraldeau@xxxxxxxxx> and Yuri Norov <ynorov@xxxxxxxxxxx> for various contributions to this work, Frederic Weisbecker <frederic@xxxxxxxxxx> for his work on CPU isolation and housekeeping that made possible to remove some less elegant solutions that I had to devise for earlier, <4.17 kernels, and Nitesh Narayan Lal <nitesh@xxxxxxxxxx> for adapting earlier patches related to interrupt and work distribution in presence of CPU isolation. -- Alex
