From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/12] arm64: psci: account for Trusted OS instances
Date: Mon, 18 May 2015 10:24:34 +0100 [thread overview]
Message-ID: <20150518092434.GA3551@leverpostej> (raw)
In-Reply-To: <CAJ5Y-ea=adURPf+kQC4QfROdk7ZiWwuM78qnHfBi7CV1L6BbRw@mail.gmail.com>
On Fri, May 15, 2015 at 04:06:39PM +0100, Ashwin Chaugule wrote:
> On 8 May 2015 at 07:36, Mark Rutland <mark.rutland@arm.com> wrote:
> > Software resident in the secure world (a "Trusted OS") may cause CPU_OFF
> > calls for the CPU it is resident on to be denied. Such a denial would be
> > fatal for the kernel, and so we must detect when this can happen before
> > the point of no return.
> >
> > This patch implements Trusted OS detection for PSCI 0.2+ systems, using
> > MIGRATE_INFO_TYPE and MIGRATE_INFO_UP_CPU. When a trusted OS is detected
> > as resident on a particular CPU, attempts to hot unplug that CPU will be
> > denied early, before they can prove fatal.
> >
> > Trusted OS migration is not implemented by this patch. Implementation of
> > migratable UP trusted OSs seems unlikely, and the right policy for
> > migration is unclear (and will likely differ across implementations). As
> > such, it is likely that migration will require cooperation with Trusted
> > OS drivers.
> >
> > PSCI implementations prior to 0.1 do not provide the facility to detect
> > the presence of a Trusted OS, nor the CPU any such OS is resident on, so
> > without additional information it is not possible to handle Trusted OSs
> > with PSCI 0.1.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/kernel/psci.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 61 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> > index 7324db9..25e2610 100644
> > --- a/arch/arm64/kernel/psci.c
> > +++ b/arch/arm64/kernel/psci.c
> > @@ -43,6 +43,19 @@ struct psci_power_state {
> > u8 affinity_level;
> > };
> >
> > +/*
> > + * The CPU any Trusted OS is resident on. The trusted OS may reject CPU_OFF
> > + * calls to its resident CPU, so we must avoid issuing those. We never migrate
> > + * a Trusted OS even if it claims to be capable of migration -- doing so will
> > + * require cooperation with a Trusted OS driver.
> > + */
> > +static int resident_cpu = -1;
> > +
> > +static bool psci_tos_resident_on(int cpu)
> > +{
> > + return cpu == resident_cpu;
> > +}
[...]
> > +/*
> > + * Detect the presence of a resident Trusted OS which may cause CPU_OFF to
> > + * return DENIED (which would be fatal).
> > + */
> > +static void __init psci_init_migrate(void)
> > +{
> > + unsigned long cpuid;
> > + int type, cpu = -1;
> > +
> > + type = psci_ops.migrate_info_type();
> > +
> > + if (type == PSCI_0_2_TOS_MP) {
> > + pr_info("Trusted OS migration not required\n");
> > + return;
> > + }
> > +
> > + if (type == PSCI_RET_NOT_SUPPORTED) {
> > + pr_info("MIGRATE_INFO_TYPE not supported.\n");
> > + return;
> > + }
> > +
> > + if (type != PSCI_0_2_TOS_UP_MIGRATE &&
> > + type != PSCI_0_2_TOS_UP_NO_MIGRATE) {
> > + pr_err("MIGRATE_INFO_TYPE returned unknown type (%d)\n", type);
> > + return;
> > + }
> > +
> > + cpuid = psci_ops.migrate_info_up_cpu();
>
> [..]
>
> > + cpu = get_logical_index(cpuid);
> > + resident_cpu = cpu >= 0 ? cpu : -1;
> > +
> > + pr_info("Trusted OS resident on physical CPU 0x%lx\n", cpuid);
> > +}
[...]
> > @@ -449,6 +505,11 @@ static int cpu_psci_cpu_disable(unsigned int cpu)
> > /* Fail early if we don't have CPU_OFF support */
> > if (!psci_ops.cpu_off)
> > return -EOPNOTSUPP;
> > +
> > + /* Trusted OS will deny CPU_OFF */
> > + if (psci_tos_resident_on(cpu))
>
> IIUC, you're denying CPU_OFF even if MIGRATE_INFO_TYPE = 2. Is that correct?
>
Yes, though only for the CPU the TOS is resident on.
It's not clear what the right policy is w.r.t. migration, and it's
probably going to depend on the TOS and workload. It's also not clear
whether there are migrateable UP TOS instances out there.
So for the moment this just ensures we won't accidentally bring the
system down in the presence of a UP TOS (migrateable or otherwise).
Thanks.
Mark.
next prev parent reply other threads:[~2015-05-18 9:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 11:36 [PATCH 00/12] arm/arm64: Unify PSCI client support Mark Rutland
2015-05-08 11:36 ` [PATCH 01/12] arm/arm64: kvm: add missing PSCI include Mark Rutland
2015-05-12 14:07 ` Christoffer Dall
2015-05-08 11:36 ` [PATCH 02/12] arm64: smp_plat: add get_logical_index Mark Rutland
2015-05-08 11:36 ` [PATCH 03/12] arm64: smp: consistently use error codes Mark Rutland
2015-05-08 11:36 ` [PATCH 04/12] arm64: psci: remove unnecessary id indirection Mark Rutland
2015-05-08 11:36 ` [PATCH 05/12] arm64: psci: support unsigned return values Mark Rutland
2015-05-11 12:25 ` Lorenzo Pieralisi
2015-05-11 12:39 ` Mark Rutland
2015-05-08 11:36 ` [PATCH 06/12] arm64: psci: account for Trusted OS instances Mark Rutland
2015-05-13 14:22 ` Lorenzo Pieralisi
2015-05-18 10:04 ` Mark Rutland
2015-05-15 15:06 ` Ashwin Chaugule
2015-05-18 9:24 ` Mark Rutland [this message]
2015-05-08 11:36 ` [PATCH 07/12] arm64: psci: kill psci_power_state Mark Rutland
2015-05-11 15:32 ` Lorenzo Pieralisi
2015-05-08 11:36 ` [PATCH 08/12] arm64: psci: remove ACPI coupling Mark Rutland
2015-05-15 15:10 ` Ashwin Chaugule
2015-05-08 11:36 ` [PATCH 09/12] arm64: psci: factor invocation code to drivers Mark Rutland
2015-05-13 9:40 ` Mark Rutland
2015-05-08 11:36 ` [PATCH 10/12] drivers: psci: support native SMC{32,64} calls Mark Rutland
2015-05-08 11:36 ` [PATCH 11/12] ARM: migrate to common PSCI client code Mark Rutland
2015-05-15 15:41 ` Ashwin Chaugule
2015-05-15 15:43 ` Ashwin Chaugule
2015-05-18 9:46 ` Mark Rutland
2015-05-18 19:14 ` Ashwin Chaugule
2015-05-26 12:59 ` Mark Rutland
2015-05-08 11:36 ` [PATCH 12/12] MAINTAINERS: add PSCI entry Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150518092434.GA3551@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox