Messages in this thread | | | Date | Sat, 05 Jun 2021 11:15:51 +0100 | From | Marc Zyngier <> | Subject | Re: [PATCHv2 2/2] kvm: x86: implement KVM PM-notifier |
| |
On Sat, 05 Jun 2021 11:03:40 +0100, Sergey Senozhatsky <senozhatsky@chromium.org> wrote: > > On (21/06/05 18:58), Sergey Senozhatsky wrote: > [..] > > > > +static int kvm_arch_suspend_notifier(struct kvm *kvm) > > > > +{ > > > > + struct kvm_vcpu *vcpu; > > > > + int i, ret; > > > > + > > > > + mutex_lock(&kvm->lock); > > > > + kvm_for_each_vcpu(i, vcpu, kvm) { > > > > + ret = kvm_set_guest_paused(vcpu); > > > > + if (ret) { > > > > + pr_err("Failed to pause guest VCPU%d: %d\n", > > > > + vcpu->vcpu_id, ret); > > > > > > Is it really a good idea to fail suspend when a guest doesn't have PV > > > time enabled? I also wonder how useful the pr_err() is, given that it > > > contains no information that would help identifying which guest failed > > > to pause. > > > > No opinion. What shall we do when we fail to suspend the VM? > > VM's watchdogs will trigger and maybe panic the system after > > resume.
Panic the guest, maybe. Panic the host, surely not? You cannot decide what the guest uses or doesn't use anyway, so that's out of your hands. I don't think this should prevent the host from suspending, in any case.
> For the time being kvm_set_guest_paused() errors out when > !vcpu->arch.pv_time_enabled, but this probably can change in the > future (who knows?). So shall I check vcpu->arch.pv_time_enabled in > kvm_arch_suspend_notifier()?
That, or check for the -EINVAL return value.
M.
-- Without deviation from the norm, progress is not possible.
| |