From patchwork Wed Jun 3 01:23:45 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Glauber Costa X-Patchwork-Id: 27594 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n531I75G023233 for ; Wed, 3 Jun 2009 01:18:07 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751351AbZFCBSB (ORCPT ); Tue, 2 Jun 2009 21:18:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751344AbZFCBSB (ORCPT ); Tue, 2 Jun 2009 21:18:01 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59015 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbZFCBSA (ORCPT ); Tue, 2 Jun 2009 21:18:00 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n531I2Hi009699; Tue, 2 Jun 2009 21:18:02 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n531I1f6003725; Tue, 2 Jun 2009 21:18:01 -0400 Received: from poweredge.glommer (vpn-10-57.bos.redhat.com [10.16.10.57]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n531Hx9K021665; Tue, 2 Jun 2009 21:17:59 -0400 Date: Tue, 2 Jun 2009 22:23:45 -0300 From: Glauber Costa To: Jan Kiszka Cc: kvm@vger.kernel.org, avi@redhat.com Subject: Re: [PATCH 1/4] always halt non-bsp cpu. Message-ID: <20090603012345.GB30777@poweredge.glommer> References: <1243971470-31676-1-git-send-email-glommer@redhat.com> <1243971470-31676-2-git-send-email-glommer@redhat.com> <4A258D23.9080106@web.de> <20090602212340.GX30777@poweredge.glommer> <4A25A11C.3090700@web.de> <20090602220937.GY30777@poweredge.glommer> <4A25A864.2070006@web.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4A25A864.2070006@web.de> X-ChuckNorris: True User-Agent: Jack Bauer X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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 Date: Tue Jun 2 21:15:57 2009 -0400 test patch Signed-off-by: Glauber Costa 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))