On 02/09/2010 10:58 PM, Marcelo Tosatti wrote:
You're right... this should be enough to avoid a stop with uncomplete
PIO (and this is what happens for MMIO already). The signal will not
be dequeued, so KVM will complete_pio and exit before entering with
-EAGAIN. Please review and queue for stable.
Not right enough. This is very fragile, we depend on the kernel
noticing the signal after completing pio but before starting execution.
I don't think we guarantee that.
Maybe we should turn complete_pio/complete_mmio to an ioctl, so that we
can control what happens exactly. Or maybe it's simplest to document it
as a feature and guarantee it. There's some merit in it - only guest
execution is the nonatomic part, so we only interrupt that.
qemu upstream needs a bit more work.
Could be as simple as raising a blocked exception that is unmasked by
kvm, then entering the guest.
-------
Re-enter the kernel to complete in progress PIO. Otherwise the
operation can be lost during migration.
Signed-off-by: Marcelo Tosatti<mtosatti@xxxxxxxxxx>
Index: qemu-kvm/qemu-kvm.c
===================================================================
--- qemu-kvm.orig/qemu-kvm.c
+++ qemu-kvm/qemu-kvm.c
@@ -967,6 +967,7 @@ int kvm_run(CPUState *env)
run->io.direction,
run->io.size,
run->io.count);
+ r = 0;
break;
case KVM_EXIT_DEBUG:
r = handle_debug(env);
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
