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 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
