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

[Avi Kivity <avi@redhat.com>]

On 08/02/2012 11:29 PM, Benjamin Herrenschmidt wrote:
> 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.

That happens naturally if you update (or read) registers through a
run_on_cpu() call.  run_on_cpu() should never happen within an mmio
sequence.

> 
> 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 ?

I'm afraid I no longer know the details so closely, the code has changed
quite a lot.  But the self-signal happens in kvm_cpu_exec(), see also
env->exit_request.


-- 
error compiling committee.c: too many arguments to function