From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/4] always halt non-bsp cpu. Date: Wed, 03 Jun 2009 13:01:29 +0200 Message-ID: <4A265809.3020908@siemens.com> 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> <20090603012345.GB30777@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, avi@redhat.com To: Glauber Costa Return-path: Received: from gecko.sbs.de ([194.138.37.40]:21305 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752333AbZFCLBv (ORCPT ); Wed, 3 Jun 2009 07:01:51 -0400 In-Reply-To: <20090603012345.GB30777@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: 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 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux