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:03:30 +0200 Message-ID: <4A265882.6040704@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> <20090603010159.GA30777@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, avi@redhat.com To: Glauber Costa Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:17996 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751484AbZFCLD4 (ORCPT ); Wed, 3 Jun 2009 07:03:56 -0400 In-Reply-To: <20090603010159.GA30777@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. > Jan, can you be more specific on why it breaks? I'm double trying it > here, and it works for me just fine. > It locked up in the BIOS after reset from a booted SMP guest, somewhere before selecting the boot device. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux