Hi Thomas,
On 09/11/16 10:15, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Matt Redfearn wrote:
The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. The CPU must be
offlined from Linux first. A sysfs interface is created which allows
firmware to be loaded and changed at runtime. A full description is
available at [1]. An example firmware that can be used with this driver
is available at [2].
This is useful to allow running bare metal code, or an RTOS, on one or
more CPUs while allowing Linux to continue running on those remaining.
And how is actually guaranteed that these two things are properly seperated
(memory, devices, interrupts etc.) ?
Memory separation is primarily handled by the remoteproc subsystem,
which will allocate and map memory as required by the firmware, though
because the CPU is executing in kernel mode there is nothing preventing
it accessing anything in the system. But that is of course the same as
any root process which could do the same thing via /dev/mem. One must be
root to offline the CPU from Linux and load firmware to it, so there is
no greater hazard to the system than that firmware running as a root
process within userland.
Separation of devices and interrupts is a system design issue, as this
feature will find use in embedded systems where the system will be
partitioned into Linux and bare metal components. This is done where
there are requirements such as needing to run real time code as well as
Linux, or enforce separation through firmware binaries running
separately to Linux.
This would be useful, for example, for a modem driver running as bare
metal code within one of the system VPEs and providing a virtio-net
interface to the kernel. There would be no kernel driver present for
such a device, therefore there would be no resource conflicts.
There only different thing about the MIPS implementation of remoteproc
is that it turns one of the general purpose Linux CPUs into a remote
processor, rather than there being a separate remote CPU within the SoC,
as is the case with most remoteproc drivers. But unless there is some
form of MMU between that CPU and the system bus, then it will have the
same ability to access all system resources as is the case with this
driver. Again I don't think there is any greater risk to the system here
as there would be with any other remoteproc based system.
We have rejected attempts to do exactly the same thing on x86 in the
past. There is virtualization and NOHZ_FULL to do it proper and not just
with a horrible hackery.
There is already a mechanism to do this in the upstream MIPS kernel -
the VPE loader, which has been there 2005 (commit
e01402b115cccb6357f956649487aca2c6f7fbba). One user of the VPE loader
was Lantiq, who used it to load a proprietary modem driver, for which
there is no GPL driver.
What we are proposing here is to move from that MIPS specific mechanism
of running bare metal code to the standardized remoteproc subsystem such
that people wanting to design a MIPS based system with both real time
firmware and general Linux processing tasks may do so using standardized
kernel interfaces.
Thanks,
Matt
Thanks,
tglx
