Re: [PATCH] Allow to call vm_stop from vcpu thread

[Jan Kiszka <jan.kiszka@siemens.com>]

Gleb Natapov wrote:
> On Thu, Jan 15, 2009 at 02:43:49PM +0100, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> Signed-off-by: Gleb Natapov <gleb@redhat.com>
>>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>>> index e4fba78..484a232 100644
>>> --- a/qemu/qemu-kvm.c
>>> +++ b/qemu/qemu-kvm.c
>>> @@ -296,11 +296,15 @@ static void pause_all_threads(void)
>>>  {
>>>      CPUState *penv = first_cpu;
>>>  
>>> -    assert(!cpu_single_env);
>>> -
>>>      while (penv) {
>>> -        penv->kvm_cpu_state.stop = 1;
>>> -        pthread_kill(penv->kvm_cpu_state.thread, SIG_IPI);
>>> +        if (penv != cpu_single_env) {
>>> +            penv->kvm_cpu_state.stop = 1;
>>> +            pthread_kill(penv->kvm_cpu_state.thread, SIG_IPI);
>>> +        } else {
>>> +            penv->kvm_cpu_state.stop = 0;
>>> +            penv->kvm_cpu_state.stopped = 1;
>>> +            cpu_interrupt(penv, CPU_INTERRUPT_EXIT);
>>> +        }
>>>          penv = (CPUState *)penv->next_cpu;
>>>      }
>> Who do you have in mind to use this? At least the debugging
> I need this for ENOSPC patches. When IDE is in PIO mode KVM do
> synchronous writes from vcpu context. We have to be able to call
> vm_stop() if synchronous write returns ENOSPC.
> 
>> infrastructure could do so, but I do not recall ATM if there were
>> limitations that the above change may not overcome. Maybe you could test
>> your patch by changing (probably simplifying) the path from a breakpoint
>> hit to vm_stop.
>>
> I am testing it with my ENOSPC patches and 2 cpus and don't see any ill
> effects yet.

Great! When done, a supplementary patch to overcome
kvm_debug_cpu_requested would be welcome, too. :)

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux