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();
}
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
