diff mbox

[1/4] always halt non-bsp cpu.

Message ID 20090603012345.GB30777@poweredge.glommer (mailing list archive)
State New, archived
Headers show

Commit Message

Glauber Costa June 3, 2009, 1:23 a.m. UTC
On Wed, Jun 03, 2009 at 12:32:04AM +0200, Jan Kiszka wrote:
> Glauber Costa wrote:
> > On Wed, Jun 03, 2009 at 12:01:00AM +0200, Jan Kiszka wrote:
> >> Glauber Costa wrote:
> >>> On Tue, Jun 02, 2009 at 10:35:47PM +0200, Jan Kiszka wrote:
> >>>> Glauber Costa wrote:
> >>>>> This is not kvm specific, and should do fine in plain qemu
> >>>> This is fine with plain qemu already. The problem, IIUC, is that
> >>>> in-kernel kvm irqchip does not have a chance to remove the halted state
> >>>> again. Did you test the effect of this patch on that scenario? What
> >>>> makes it safe to be removed now?
> >>> IIRC, the in kernel irqchip sets halted = 0 in the very beginning of
> >>> the vcpu initialization.
> >>>
> >>> It is tested here with in-kernel irqchip and works, so probably not
> >>> a problem, unless you can spot something.
> >> At least your patch applied alone breaks -smp >1 here.
> >>
> >> But the whole management of env->halted for the in-kernel irqchip in
> >> qemu-kvm is a bit hacky IMHO. Maybe it's time to rethink this. Would be
> >> nice to always see a consistent halted in user space, specifically for
> >> debugging purposes.
> > out of curiosity: did you apply the whole series?
> 
> Meanwhile I did, but it makes no difference.
> 

Can you try putting the following patch before this one?
commit 0bca36c13cb402ea33ad615d8d4f9882d1284f02
Author: Glauber Costa <glommer@redhat.com>
Date:   Tue Jun 2 21:15:57 2009 -0400

    test patch
    
    Signed-off-by: Glauber Costa <glommer@redhat.com>

Comments

Jan Kiszka June 3, 2009, 11:01 a.m. UTC | #1
Glauber Costa wrote:
> On Wed, Jun 03, 2009 at 12:32:04AM +0200, Jan Kiszka wrote:
>> Glauber Costa wrote:
>>> On Wed, Jun 03, 2009 at 12:01:00AM +0200, Jan Kiszka wrote:
>>>> Glauber Costa wrote:
>>>>> On Tue, Jun 02, 2009 at 10:35:47PM +0200, Jan Kiszka wrote:
>>>>>> Glauber Costa wrote:
>>>>>>> This is not kvm specific, and should do fine in plain qemu
>>>>>> This is fine with plain qemu already. The problem, IIUC, is that
>>>>>> in-kernel kvm irqchip does not have a chance to remove the halted state
>>>>>> again. Did you test the effect of this patch on that scenario? What
>>>>>> makes it safe to be removed now?
>>>>> IIRC, the in kernel irqchip sets halted = 0 in the very beginning of
>>>>> the vcpu initialization.
>>>>>
>>>>> It is tested here with in-kernel irqchip and works, so probably not
>>>>> a problem, unless you can spot something.
>>>> At least your patch applied alone breaks -smp >1 here.
>>>>
>>>> But the whole management of env->halted for the in-kernel irqchip in
>>>> qemu-kvm is a bit hacky IMHO. Maybe it's time to rethink this. Would be
>>>> nice to always see a consistent halted in user space, specifically for
>>>> debugging purposes.
>>> out of curiosity: did you apply the whole series?
>> Meanwhile I did, but it makes no difference.
>>
> 
> Can you try putting the following patch before this one?

If it helps you to understand the issue, I will do so later.

But I *really* suggest to take this chance and develop in-kernel irqchip
support that does not mess with halted, rather keeps it consistent (on
register sync) and maybe adds exceptions from "if (!env->halted)" tests
where required. IMHO, this is mandatory for an upstream merge!

Jan
Gleb Natapov June 3, 2009, 11:11 a.m. UTC | #2
On Wed, Jun 03, 2009 at 01:01:29PM +0200, Jan Kiszka wrote:
> Glauber Costa wrote:
> > On Wed, Jun 03, 2009 at 12:32:04AM +0200, Jan Kiszka wrote:
> >> Glauber Costa wrote:
> >>> On Wed, Jun 03, 2009 at 12:01:00AM +0200, Jan Kiszka wrote:
> >>>> Glauber Costa wrote:
> >>>>> On Tue, Jun 02, 2009 at 10:35:47PM +0200, Jan Kiszka wrote:
> >>>>>> Glauber Costa wrote:
> >>>>>>> This is not kvm specific, and should do fine in plain qemu
> >>>>>> This is fine with plain qemu already. The problem, IIUC, is that
> >>>>>> in-kernel kvm irqchip does not have a chance to remove the halted state
> >>>>>> again. Did you test the effect of this patch on that scenario? What
> >>>>>> makes it safe to be removed now?
> >>>>> IIRC, the in kernel irqchip sets halted = 0 in the very beginning of
> >>>>> the vcpu initialization.
> >>>>>
> >>>>> It is tested here with in-kernel irqchip and works, so probably not
> >>>>> a problem, unless you can spot something.
> >>>> At least your patch applied alone breaks -smp >1 here.
> >>>>
> >>>> But the whole management of env->halted for the in-kernel irqchip in
> >>>> qemu-kvm is a bit hacky IMHO. Maybe it's time to rethink this. Would be
> >>>> nice to always see a consistent halted in user space, specifically for
> >>>> debugging purposes.
> >>> out of curiosity: did you apply the whole series?
> >> Meanwhile I did, but it makes no difference.
> >>
> > 
> > Can you try putting the following patch before this one?
> 
> If it helps you to understand the issue, I will do so later.
> 
> But I *really* suggest to take this chance and develop in-kernel irqchip
> support that does not mess with halted, rather keeps it consistent (on
> register sync) and maybe adds exceptions from "if (!env->halted)" tests
> where required. IMHO, this is mandatory for an upstream merge!
> 
The difference between kernel/userspace irq chip is that in
former case halted cpu sleeps in the kernel and in later case in the
usespace (well also in the kernel but not in kvm code). We currently
abuse halted to do different sleeps. Cpu loop should be reworked.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/qemu-kvm.c b/qemu-kvm.c
index 68d3b92..519a6ee 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -390,8 +390,6 @@  static int kvm_main_loop_cpu(CPUState *env)
     setup_kernel_sigmask(env);
 
     pthread_mutex_lock(&qemu_mutex);
-    if (kvm_irqchip_in_kernel(kvm_context))
-	env->halted = 0;
 
     kvm_qemu_init_env(env);
 #ifdef TARGET_I386
@@ -402,6 +400,9 @@  static int kvm_main_loop_cpu(CPUState *env)
     kvm_load_registers(env);
 
     while (1) {
+
+    if (kvm_irqchip_in_kernel(kvm_context))
+    	env->halted = 0;
 	while (!has_work(env))
 	    kvm_main_loop_wait(env, 1000);
 	if (env->interrupt_request & (CPU_INTERRUPT_HARD | CPU_INTERRUPT_NMI))