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.