[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: |
Bharata B Rao |
Subject: |
Re: [PATCH v2 ppc-for-5.0 2/2] ppc/spapr: Support reboot of secure pseries guest |
Date: |
Fri, 13 Dec 2019 09:34:38 +0530 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Thu, Dec 12, 2019 at 01:27:23PM +0100, Greg Kurz wrote:
> > 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 ?
We are in machine reset path, so all vcpus are already paused. So we don't
expect any vcpus to be running to handle -EBUSY here. Neither do I see any
sane recovery path from here.
As Alexey mentioned earlier, may be we can just stop the VM?
Do vm_stop() with RUN_STATE_PAUSED or some such reason?
Regards,
Bharata.