All of lore.kernel.org
 help / color / mirror / Atom feed
From: ashwin.chaugule@linaro.org (Ashwin Chaugule)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/12] arm64: psci: account for Trusted OS instances
Date: Fri, 15 May 2015 11:06:39 -0400	[thread overview]
Message-ID: <CAJ5Y-ea=adURPf+kQC4QfROdk7ZiWwuM78qnHfBi7CV1L6BbRw@mail.gmail.com> (raw)
In-Reply-To: <1431085004-32743-7-git-send-email-mark.rutland@arm.com>

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;
> +}
> +
>  struct psci_operations {
>         int (*cpu_suspend)(struct psci_power_state state,
>                            unsigned long entry_point);
> @@ -52,6 +65,7 @@ struct psci_operations {
>         int (*affinity_info)(unsigned long target_affinity,
>                         unsigned long lowest_affinity_level);
>         int (*migrate_info_type)(void);
> +       unsigned long (*migrate_info_up_cpu)(void);
>  };
>
>  static struct psci_operations psci_ops;
> @@ -172,6 +186,11 @@ static int psci_migrate_info_type(void)
>         return invoke_psci_fn(PSCI_0_2_FN_MIGRATE_INFO_TYPE, 0, 0, 0);
>  }
>
> +static unsigned long psci_migrate_info_up_cpu(void)
> +{
> +       return invoke_psci_fn(PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU, 0, 0, 0);
> +}
> +
>  static int __maybe_unused cpu_psci_cpu_init_idle(struct device_node *cpu_node,
>                                                  unsigned int cpu)
>  {
> @@ -261,6 +280,40 @@ static void psci_sys_poweroff(void)
>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>
> +/*
> + * 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);
> +}
> +
>  static void __init psci_0_2_set_functions(void)
>  {
>         pr_info("Using standard PSCI v0.2 function IDs\n");
> @@ -279,6 +332,7 @@ static void __init psci_0_2_set_functions(void)
>         psci_ops.affinity_info = psci_affinity_info;
>
>         psci_ops.migrate_info_type = psci_migrate_info_type;
> +       psci_ops.migrate_info_up_cpu = psci_migrate_info_up_cpu;
>
>         arm_pm_restart = psci_sys_reset;
>
> @@ -303,6 +357,8 @@ static int __init psci_probe(void)
>
>         psci_0_2_set_functions();
>
> +       psci_init_migrate();
> +
>         return 0;
>  }
>
> @@ -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?

  parent reply	other threads:[~2015-05-15 15:06 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 [this message]
2015-05-18  9:24     ` Mark Rutland
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='CAJ5Y-ea=adURPf+kQC4QfROdk7ZiWwuM78qnHfBi7CV1L6BbRw@mail.gmail.com' \
    --to=ashwin.chaugule@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.