On Fri, Aug 03, 2012 at 02:41:13PM -0300, Marcelo Tosatti wrote:
> On Fri, Aug 03, 2012 at 06:20:18AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
> > > This is actually documented in api.txt, though not in relation to
> > > reset:
> > > 
> > >   NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the
> > >   corresponding operations are complete (and guest state is
> > > consistent)
> > >   only after userspace has re-entered the kernel with KVM_RUN.  The
> > >   kernel side will first finish incomplete operations and then check
> > >   for pending signals.  Userspace can re-enter the guest with an
> > >   unmasked signal pending to complete pending operations.
> > > 
> > > For x86 the issue was with live migration - you can't copy guest
> > > register state in the middle of an I/O operation.  Reset is actually
> > > similar, but it involves writing state (which can then be overwritten)
> > > instead of reading it.
> > 
> > Hrm, except that doing KVM_RUN with a signal is very cumbersome to do
> > and I couldn't quite find the logic in qemu to do it ... but I might
> > just have missed it. I can see indeed that in the migration case you
> > want to actually complete the operation rather than just "abort it".
> > 
> > Any chance you can point me to the code that performs that trick qemu
> > side for migration ?
> 
> kvm-all.c:
> 
>         kvm_arch_pre_run(env, run);
>         if (env->exit_request) {
>             DPRINTF("interrupt exit requested\n");
>             /*
>              * KVM requires us to reenter the kernel after IO exits to
>              * complete
>              * instruction emulation. This self-signal will ensure that
>              * we
>              * leave ASAP again.
>              */
>             qemu_cpu_kick_self();
>         }


See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.

The whole thing is fragile, though: we rely on the order events
are processed inside KVM_RUN, in x86:

1) If there is pending MMIO, process it.
2) If not, return with -EINTR (and KVM_EXIT_INTR) in case
there is a signal pending.

That way, the vcpu will not process the stop event from the main loop
(ie not exit from the kvm_cpu_exec() loop), until MMIO is finished.

> > Anthony seems to think that for reset we can just abort the operation
> > state in the kernel when the MP state changes.
> > 
> > Cheers,
> > Ben.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to