Re: [kvm-devel] [PATCH 2/2] qemu-kvm: Fix guest resetting v2

[Avi K. <av...@qu...>]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> Resetting guests used to be racy, deadlock-prone, or simply broken (for
>>> SMP). This patch fixes the issues, following Marcelo's suggestion to
>>> consolidate the reset activity in the I/O thread. All vcpus are cleanly
>>> stopped before the emulated hardware is reset, and kvm_arch_cpu_reset is
>>> introduced and invoked to ensure that non-boot cpus are put into the
>>> right state on x86. Note that other arch may need to look into this
>>> service as well to get SMP reset right.
>>>
>>>   
>>>       
>> hmm.  This means that reset is executed asynchronously of the calling cpu.
>>     
>
> Nope, the calling cpu is put in stopped state after informing the I/O
> thread about the reset request. We just cannot control when the request
> is handled /wrt to other cpus, but that's not different from real life I
> guess.
>   

That's true for triple-faults, but not for ordinary keyboard controller 
resets.  All you do there is call main_loop_break().

But I think that's fine; on a real machine the keyboard controller reset 
is processed by a separate processor (the keyboard controller) which has 
nonzero latency.

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