Re: [PATCH v4 0/4] MIPS: Remote processor driver

From: Matt Redfearn
Date: Wed Nov 09 2016 - 08:30:27 EST


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