question about arch/s390/kvm/interrupt.c

question about arch/s390/kvm/interrupt.c

[Julia Lawall]

In a recent version of linux-next, the function kvm_s390_handle_wait 
contains the following code:

        add_wait_queue(&vcpu->arch.local_int.wq, &wait);
        while (list_empty(&vcpu->arch.local_int.list) &&
                list_empty(&vcpu->arch.local_int.float_int->list) &&
                (!vcpu->arch.local_int.timer_due) &&
                !signal_pending(current)) {
                set_current_state(TASK_INTERRUPTIBLE);
                spin_unlock_bh(&vcpu->arch.local_int.lock);
                spin_unlock(&vcpu->arch.local_int.float_int->lock);
                vcpu_put(vcpu);
                schedule();
                vcpu_load(vcpu);
                spin_lock(&vcpu->arch.local_int.float_int->lock);
                spin_lock_bh(&vcpu->arch.local_int.lock);
        }
        __unset_cpu_idle(vcpu);
        __set_current_state(TASK_RUNNING);
        remove_wait_queue(&vcpu->wq, &wait);

It seems a bit odd that the first argument to add_wait queue is 
&vcpu->arch.local_int.wq but the first argument to remove_wait_queue is 
&vcpu->wq.  I don't see any obvious evidence that they are the same thing, 
but perhaps I am missing something.  Should either call be changed?

julia

Re: question about arch/s390/kvm/interrupt.c

[Avi Kivity]

(copying some s390 people)

On 07/10/2009 02:47 PM, Julia Lawall wrote:
> In a recent version of linux-next, the function kvm_s390_handle_wait
> contains the following code:
>
>          add_wait_queue(&vcpu->arch.local_int.wq,&wait);
>          while (list_empty(&vcpu->arch.local_int.list)&&
>                  list_empty(&vcpu->arch.local_int.float_int->list)&&
>                  (!vcpu->arch.local_int.timer_due)&&
>                  !signal_pending(current)) {
>                  set_current_state(TASK_INTERRUPTIBLE);
>                  spin_unlock_bh(&vcpu->arch.local_int.lock);
>                  spin_unlock(&vcpu->arch.local_int.float_int->lock);
>                  vcpu_put(vcpu);
>                  schedule();
>                  vcpu_load(vcpu);
>                  spin_lock(&vcpu->arch.local_int.float_int->lock);
>                  spin_lock_bh(&vcpu->arch.local_int.lock);
>          }
>          __unset_cpu_idle(vcpu);
>          __set_current_state(TASK_RUNNING);
>          remove_wait_queue(&vcpu->wq,&wait);
>
> It seems a bit odd that the first argument to add_wait queue is
> &vcpu->arch.local_int.wq but the first argument to remove_wait_queue is
> &vcpu->wq.  I don't see any obvious evidence that they are the same thing,
> but perhaps I am missing something.  Should either call be changed?
>
> julia
>    


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

Re: question about arch/s390/kvm/interrupt.c

[Carsten Otte]

> (copying some s390 people)
> 
> On 07/10/2009 02:47 PM, Julia Lawall wrote:
> > In a recent version of linux-next, the function kvm_s390_handle_wait
> > contains the following code:
> >
> >          add_wait_queue(&vcpu->arch.local_int.wq,&wait);
> >          while (list_empty(&vcpu->arch.local_int.list)&&
> >                  list_empty(&vcpu->arch.local_int.float_int->list)&&
> >                  (!vcpu->arch.local_int.timer_due)&&
> >                  !signal_pending(current)) {
> >                  set_current_state(TASK_INTERRUPTIBLE);
> >                  spin_unlock_bh(&vcpu->arch.local_int.lock);
> >                  spin_unlock(&vcpu->arch.local_int.float_int->lock);
> >                  vcpu_put(vcpu);
> >                  schedule();
> >                  vcpu_load(vcpu);
> >                  spin_lock(&vcpu->arch.local_int.float_int->lock);
> >                  spin_lock_bh(&vcpu->arch.local_int.lock);
> >          }
> >          __unset_cpu_idle(vcpu);
> >          __set_current_state(TASK_RUNNING);
> >          remove_wait_queue(&vcpu->wq,&wait);
> >
> > It seems a bit odd that the first argument to add_wait queue is
> > &vcpu->arch.local_int.wq but the first argument to remove_wait_queue is
> > &vcpu->wq.  I don't see any obvious evidence that they are the same thing,
> > but perhaps I am missing something.  Should either call be changed?
Good catch! It's broken, I'll send a fix later today.

so long,
Carsten

[PATCH] kvm-390: fix wait_queue handling

[Christian Bornträger]

From: Christian Borntraeger <borntraeger@de.ibm.com>

There are two waitqueues in kvm for wait handling:
vcpu->wq for virt/kvm/kvm_main.c and
vpcu->arch.local_int.wq for the s390 specific wait code.

the wait handling in kvm_s390_handle_wait was broken by using different
wait_queues for add_wait queue and remove_wait_queue.

There are two options to fix the problem: 
o  move all the s390 specific code to vcpu->wq and remove
   vcpu->arch.local_int.wq
o  move all the s390 specific code to vcpu->arch.local_int.wq

This patch chooses the 2nd variant for two reasons:
o  s390 does not use kvm_vcpu_block but implements its own enabled wait
   handling.
   Having a separate wait_queue make it clear, that our wait mechanism is
   different
o  the patch is much smaller

Report-by:  Julia Lawall <julia@diku.dk>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/kvm/interrupt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: kvm/arch/s390/kvm/interrupt.c
===================================================================
--- kvm.orig/arch/s390/kvm/interrupt.c
+++ kvm/arch/s390/kvm/interrupt.c
@@ -386,7 +386,7 @@ no_timer:
 	}
 	__unset_cpu_idle(vcpu);
 	__set_current_state(TASK_RUNNING);
-	remove_wait_queue(&vcpu->wq, &wait);
+	remove_wait_queue(&vcpu->arch.local_int.wq, &wait);
 	spin_unlock_bh(&vcpu->arch.local_int.lock);
 	spin_unlock(&vcpu->arch.local_int.float_int->lock);
 	hrtimer_try_to_cancel(&vcpu->arch.ckc_timer);

Re: [PATCH] kvm-390: fix wait_queue handling

[Marcelo Tosatti]

On Thu, Jul 16, 2009 at 05:17:37PM +0200, Christian Bornträger wrote:
> From: Christian Borntraeger <borntraeger@de.ibm.com>
> 
> There are two waitqueues in kvm for wait handling:
> vcpu->wq for virt/kvm/kvm_main.c and
> vpcu->arch.local_int.wq for the s390 specific wait code.
> 
> the wait handling in kvm_s390_handle_wait was broken by using different
> wait_queues for add_wait queue and remove_wait_queue.
> 
> There are two options to fix the problem: 
> o  move all the s390 specific code to vcpu->wq and remove
>    vcpu->arch.local_int.wq
> o  move all the s390 specific code to vcpu->arch.local_int.wq
> 
> This patch chooses the 2nd variant for two reasons:
> o  s390 does not use kvm_vcpu_block but implements its own enabled wait
>    handling.
>    Having a separate wait_queue make it clear, that our wait mechanism is
>    different
> o  the patch is much smaller
> 
> Report-by:  Julia Lawall <julia@diku.dk>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  arch/s390/kvm/interrupt.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: kvm/arch/s390/kvm/interrupt.c
> ===================================================================
> --- kvm.orig/arch/s390/kvm/interrupt.c
> +++ kvm/arch/s390/kvm/interrupt.c
> @@ -386,7 +386,7 @@ no_timer:
>  	}
>  	__unset_cpu_idle(vcpu);
>  	__set_current_state(TASK_RUNNING);
> -	remove_wait_queue(&vcpu->wq, &wait);
> +	remove_wait_queue(&vcpu->arch.local_int.wq, &wait);
>  	spin_unlock_bh(&vcpu->arch.local_int.lock);
>  	spin_unlock(&vcpu->arch.local_int.float_int->lock);
>  	hrtimer_try_to_cancel(&vcpu->arch.ckc_timer);

Applied, thanks.