[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseri
From: |
Greg Kurz |
Subject: |
Re: [PATCH v2 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest |
Date: |
Thu, 12 Dec 2019 13:27:23 +0100 |
On Thu, 12 Dec 2019 11:20:59 +0530
Bharata B Rao <address@hidden> wrote:
> A pseries guest can be run as a secure guest on Ultravisor-enabled
> POWER platforms. When such a secure guest is reset, we need to
> release/reset a few resources both on ultravisor and hypervisor side.
> This is achieved by invoking this new ioctl KVM_PPC_SVM_OFF from the
> machine reset path.
>
> As part of this ioctl, the secure guest is essentially transitioned
> back to normal mode so that it can reboot like a regular guest and
> become secure again.
>
> This ioctl has no effect when invoked for a normal guest. If this ioctl
> fails for a secure guest, the guest is terminated.
>
> Signed-off-by: Bharata B Rao <address@hidden>
> ---
> hw/ppc/spapr.c | 15 +++++++++++++++
> target/ppc/kvm.c | 7 +++++++
> target/ppc/kvm_ppc.h | 6 ++++++
> 3 files changed, 28 insertions(+)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index f11422fc41..25e1a3446e 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1597,6 +1597,21 @@ static void spapr_machine_reset(MachineState *machine)
> void *fdt;
> int rc;
>
> + /*
> + * KVM_PPC_SVM_OFF ioctl can fail for secure guests, check and
> + * exit in that case. However check for -ENOTTY explicitly
> + * to ensure that we don't terminate normal guests that are
> + * running on kernels which don't support this ioctl.
> + *
> + * Also, this ioctl returns 0 for normal guests on kernels where
> + * this ioctl is supported.
> + */
> + rc = kvmppc_svm_off();
> + if (rc && rc != -ENOTTY) {
This ioctl can also return -EINVAL if the ultravisor actually failed to move
the guest back to non-secure mode or -EBUSY if a vCPU is still running. I
agree that the former deserve the VM to be terminated. What about the latter ?
Can this happen and if yes, why ? Should we try again as suggested by Alexey ?
Could this reveal a bug in QEMU, in which case we should maybe abort ?
> + error_report("Reset of secure guest failed, exiting...");
> + exit(EXIT_FAILURE);
> + }
> +
> spapr_caps_apply(spapr);
>
> first_ppc_cpu = POWERPC_CPU(first_cpu);
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 7406d18945..1a86fa4f0c 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2900,3 +2900,10 @@ void kvmppc_set_reg_tb_offset(PowerPCCPU *cpu, int64_t
> tb_offset)
> kvm_set_one_reg(cs, KVM_REG_PPC_TB_OFFSET, &tb_offset);
> }
> }
> +
> +int kvmppc_svm_off(void)
> +{
> + KVMState *s = KVM_STATE(current_machine->accelerator);
> +
> + return kvm_vm_ioctl(s, KVM_PPC_SVM_OFF);
> +}
> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
> index 47b08a4030..5cc812e486 100644
> --- a/target/ppc/kvm_ppc.h
> +++ b/target/ppc/kvm_ppc.h
> @@ -37,6 +37,7 @@ int kvmppc_booke_watchdog_enable(PowerPCCPU *cpu);
> target_ulong kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
> bool radix, bool gtse,
> uint64_t proc_tbl);
> +int kvmppc_svm_off(void);
> #ifndef CONFIG_USER_ONLY
> bool kvmppc_spapr_use_multitce(void);
> int kvmppc_spapr_enable_inkernel_multitce(void);
> @@ -201,6 +202,11 @@ static inline target_ulong
> kvmppc_configure_v3_mmu(PowerPCCPU *cpu,
> return 0;
> }
>
> +static inline int kvmppc_svm_off(void)
> +{
> + return 0;
> +}
> +
> static inline void kvmppc_set_reg_ppc_online(PowerPCCPU *cpu,
> unsigned int online)
> {