On 27.08.2013, at 11:03, Alexey Kardashevskiy wrote: > On 08/27/2013 06:54 PM, Alexander Graf wrote: >> >> On 27.08.2013, at 09:41, Alexey Kardashevskiy wrote: >> >>> On 08/27/2013 05:02 PM, Paolo Bonzini wrote: >>>> Il 27/08/2013 08:37, Alexey Kardashevskiy ha scritto: >>>>>>> So this is here to make sure we don't accidentally get out of halted >>>>>>> state by an interrupt on that vcpu. Could you please somehow make that >>>>>>> part obvious? Either by adding a comment or by only explicitly masking >>>>>>> DEC and EE and a comment :). >>>>>>> >>>>>>>> + cs->exit_request = 1; >>>>>>> >>>>>>> This should probably be qemu_cpu_kick_self(). >>>>>> >>>>>> Uh, no, I don't think so. This is there purely to make sure we exit >>>>>> the inner loop, and actually test cpu_can_run() which will test >>>>>> halted. AFAICT qemu_cpu_kick_self() won't do anything similar. >>>>> >>>>> rtas_stop_self() eventually returns to kvm_cpu_exec() which calls >>>>> qemu_cpu_kick_self() and resets cs->exit_request before return so I do not >>>>> really see the difference in behaviour. And actually both ways CPU stops >>>>> in >>>>> exactly the same way. What do I miss? >>>> >>>> What about TCG? >>> >>> Oh. Right. TCG :( >>> >>> qemu_cpu_kick_self() crashes the guest and cs->exit_request works fine. >>> >>> Why? Both should work? What is the expected behavior here? Thanks. >> >> Hrm. To me exit_request always was an internal piece of state that the inner >> loop uses to find out whether to exit, but not something we should randomly >> set from a device (and hypercalls / rtas calls are very similar to devices). >> So I would like to not have any code in hw/ that modifies it. >> >> However, we need the functionality of breaking out of the main loop, I agree. > >> Maybe what you are really looking for is >> cpu_interrupt(CPU_INTERRUPT_HALT). That sets halted = 1 and exits the >> main loop, because it's an interrupt. > > cpu_interrupt(CPU_INTERRUPT_HALT) works fine for TCG but does not for KVM > (the rtas call returns to the guest and it reports BUG).
How about cpu_exit()? That looks exactly like what we need. Alex