From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933121AbcKIOTN (ORCPT ); Wed, 9 Nov 2016 09:19:13 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:58234 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933023AbcKIOTL (ORCPT ); Wed, 9 Nov 2016 09:19:11 -0500 Date: Wed, 9 Nov 2016 15:16:33 +0100 (CET) From: Thomas Gleixner To: Matt Redfearn cc: Ralf Baechle , Bjorn Andersson , Ohad Ben-Cohen , linux-mips@linux-mips.org, linux-remoteproc@vger.kernel.org, Lisa Parratt , LKML , Qais Yousef , Masahiro Yamada , Paul Gortmaker , Jason Cooper , James Hogan , Marc Zyngier , Paul Burton , Peter Zijlstra , Ingo Molnar Subject: Re: [PATCH v4 0/4] MIPS: Remote processor driver In-Reply-To: Message-ID: References: <1478103063-17653-1-git-send-email-matt.redfearn@imgtec.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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