Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1518215

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

Show all headers | View raw

On Wed, 9 Nov 2016, Matt Redfearn wrote:
> 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.

Oh yes, there is. You can deny access to /dev/mem even for root, which is a
sensible thing to do. And even a process running as root has restrictions
which the kernel can enforce.

> 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.

In theory.
 
> 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.

That's true, but that's a design issue on the SoC level where we cannot do
anything about.

> Again I don't think there is any greater risk to the system here as
> there would be with any other remoteproc based system.

Well. The whole thing is just a proliferation of a really bad mechanism,
which was rejected several times in the past. Surely MIPS as being MIPS has
this mechanism already, but that does not make it any better.

> 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.

Again, you should either use NOHZ_FULL (and you can implement a proprietary
user space driver w/o using /dev/mem) or seperate the CPUs in the boot
loader already and have some tiny piece of firmware which lets you load the
real firmware blob and control it. Ideally you use hw-virtualization, but
in absence of that you can do a halfways sane paritioning w/o abusing CPU
hotplug for this.

Thanks,

	tglx

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH v4 0/4] MIPS: Remote processor driver Matt Redfearn <matt.redfearn@imgtec.com> - 2016-11-02 17:20 +0100
  [PATCH v4 2/4] MIPS: CPS: Add VP(E) stealing Matt Redfearn <matt.redfearn@imgtec.com> - 2016-11-02 17:20 +0100
  [PATCH v4 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS Matt Redfearn <matt.redfearn@imgtec.com> - 2016-11-02 17:20 +0100
  [PATCH v4 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC Matt Redfearn <matt.redfearn@imgtec.com> - 2016-11-02 17:20 +0100
  Re: [PATCH v4 0/4] MIPS: Remote processor driver Thomas Gleixner <tglx@linutronix.de> - 2016-11-09 11:20 +0100
    Re: [PATCH v4 0/4] MIPS: Remote processor driver Matt Redfearn <matt.redfearn@imgtec.com> - 2016-11-09 14:40 +0100
      Re: [PATCH v4 0/4] MIPS: Remote processor driver Thomas Gleixner <tglx@linutronix.de> - 2016-11-09 15:30 +0100

csiph-web