Re: Reset problem vs. MMIO emulation, hypercalls, etc...

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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 ?

Anthony seems to think that for reset we can just abort the operation
state in the kernel when the MP state changes.

Cheers,
Ben.