From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rkfs1-0006Ey-57 for qemu-devel@nongnu.org; Tue, 10 Jan 2012 12:52:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rkfrz-0000Mo-Ud for qemu-devel@nongnu.org; Tue, 10 Jan 2012 12:52:25 -0500 Message-ID: <4F0C7AD0.8050208@siemens.com> Date: Tue, 10 Jan 2012 18:52:16 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1326094902-24152-1-git-send-email-yu.liu@freescale.com> <4F0B5AD8.9090602@freescale.com> <4F0B7581.90306@freescale.com> <4F0C0724.5000909@siemens.com> <4F0C78B4.6080702@freescale.com> In-Reply-To: <4F0C78B4.6080702@freescale.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [kvm-devel] [PATCH v2] kvm-ppc: halt secondary cpus when guest reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Liu Yu , "qemu-ppc@nongnu.org" , Alexander Graf , qemu-devel Developers On 2012-01-10 18:43, Scott Wood wrote: > On 01/10/2012 03:38 AM, Jan Kiszka wrote: >> On 2012-01-10 00:17, Scott Wood wrote: >>> On 01/09/2012 04:39 PM, Alexander Graf wrote: >>>> >>>> On 09.01.2012, at 22:23, Scott Wood wrote: >>>>> Alex, is there a better way to deal with the IRQ chip issue? >>>> >>>> To be honest, I'm not sure what the issue really is. >>> >>> If irqchip is enabled, env->halted won't result in a CPU being >>> considered idle -- since QEMU won't see the interrupt that wakes the >>> vcpu, and the idling is handled in the kernel. In this case we're >>> waiting for MMIO rather than an interrupt, and it's the kernel that >>> doesn't know what's going on. >>> >>> It seems wrong to use env->stopped, though, as a spin-table release >>> should not override a user's explicit request to stop a CPU. It might >>> be OK (though a bit ugly) if the only usage of env->stopped is through >>> pause_all_vcpus(), and the boot thread is the first one to be kicked >>> (though in theory the boot cpu could wake another cpu, and that could >>> wake a cpu that comes before it, causing a race with pause_all_vcpus()). >>> >>> If it is OK to use env->stopped, is there any reason not to always use >>> it (versus just with irqchip)? >> >> Why don't you wait in the kernel with in-kernel irqchip under all >> condition (except pausing VCPUs, of course) on PPC? Just like x86 does. > > We do for normal idling. This is a bit different, in that we're not > waiting for an interrupt, but for an MMIO that releases the cpu at > boot-time. Where is the state stored that declares a VCPU to wait for that event? Where is it set, where removed? What about implementing MP_STATE on PPC, at least those states that make sense? Don't you need that anyway for normal HALT<->RUNNABLE transitions? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux