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

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

On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote:
> > Yeah, we stumbled over this chunk as well. So you're saying we
> should delay the reset by invoking a self-signal if we're in such an
> operation?
> 
> Yes.  Qemu of course already supports this for migration, so it should
> be easy to add.

Adding a self signal for the CPU initiating the reset is not enough,
other VCPUs might also be in an hcall or MMIO emulation when that
happens.

It must be done for all VCPUs, so best is to look at the migration
situation.

For reset, there are two code path at play:

 - The VCPU initiating the request: It calls qemu_system_reset_request()
which calls cpu_stop_current() directly after signaling the main loop

 - The other VCPUs are then marked with the "stop" flag by the maintloop
which will then wait for them to set "stopped" to 1, which is done by
qemu_wait_io_event_common() when it sees "stop".

Now, it seems like suspend also uses that same technique. I don't
totally grasp where migration fits in that picture and where it does the
KVM_RUN with a signal pending trick to complete pending operations, any
chance you can enlighten me ?

Thanks !

Cheers,
Ben.