From owner-freebsd-arch@FreeBSD.ORG Sun Jun 3 14:42:47 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9135A106566B; Sun, 3 Jun 2012 14:42:47 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 236248FC0C; Sun, 3 Jun 2012 14:42:47 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q53EgiCq031408; Sun, 3 Jun 2012 23:42:44 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Sun, 03 Jun 2012 23:42:43 +0900 (JST) Message-Id: <20120603.234243.28389486.iwasaki@jp.FreeBSD.org> To: avg@FreeBSD.org From: Mitsuru IWASAKI In-Reply-To: <4FCB0FE5.4050607@FreeBSD.org> References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <4FCB0FE5.4050607@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-acpi@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: cpu stopping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 14:42:47 -0000 Hi, thanks for comments. > As the first thing I must admit that I haven't looked at the patch :-) Never mind :) What I'm trying to do in the patches is just to unify amd64/i386 independent part (acpi_wakeup.c) for the code maintenance, so please let's commit it first, then start re-design the cpususpend_handler(). > But really I don't see why we need to differentiate between stopped and > suspended state as both of them ultimately mean exactly the same thing - CPUs > are spinning on some condition (and they are in a well-defined place and state). Yes, amd64/i386 cpususpend_handler() is very similar to cpustop_handler() actually, some resume related procedures are added for suspend. > My view of how this should work is: > - there can be only one master CPU that controls all other (slave) CPUs > - the master sets entry and exit hooks Entry hook for suspending might be ---- ctx_fpusave(suspfpusave[cpu]); wbinvd(); CPU_SET_ATOMIC(cpu, &stopped_cpus); ---- and for stopping is ---- /* Indicate that we are stopped */ CPU_SET_ATOMIC(cpu, &stopped_cpus); ---- Correct? I think stopping hook can be replaced with suspending hook. Exit hook for suspending is ---- pmap_init_pat(); load_cr3(susppcbs[cpu]->pcb_cr3); initializecpu(); PCPU_SET(switchtime, 0); PCPU_SET(switchticks, ticks); [snip] /* Resume MCA and local APIC */ mca_resume(); lapic_setup(0); ---- For stopping should be ---- if (cpu == 0 && cpustop_restartfunc != NULL) { cpustop_restartfunc(); cpustop_restartfunc = NULL; } ---- > - the master signals slaves to enter the stop state > - the slaves execute the enter hook and start spinning on the release condition > - the master does whatever it wants to do in this special system state > - the master signals the slaves to resume > - the slave exit the spin loop and execute the exit hook I think it would be possible. However I personally think that priority of x86/x86/mp_machdep.c is higher and more effective than merging cpususpend/stop_handler(). Thanks