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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1611091111041.3501@nanos>
Date:   Wed, 9 Nov 2016 11:15:20 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Matt Redfearn <matt.redfearn@...tec.com>
cc:     Ralf Baechle <ralf@...ux-mips.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ohad Ben-Cohen <ohad@...ery.com>, linux-mips@...ux-mips.org,
        linux-remoteproc@...r.kernel.org,
        Lisa Parratt <lisa.parratt@...tec.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Qais Yousef <qsyousef@...il.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Lisa Parratt <Lisa.Parratt@...tec.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Jason Cooper <jason@...edaemon.net>,
        James Hogan <james.hogan@...tec.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Paul Burton <paul.burton@...tec.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v4 0/4] MIPS: Remote processor driver

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

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.

Thanks,

	tglx