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

[Gleb Natapov <gleb@redhat.com>]

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.

--
			Gleb.