From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 18 05:34:12 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AF525F9 for ; Thu, 18 Jul 2013 05:34:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id D0D4978D for ; Thu, 18 Jul 2013 05:34:10 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 45E19D41FB5; Thu, 18 Jul 2013 15:34:00 +1000 (EST) Date: Thu, 18 Jul 2013 15:33:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Revisiting FPU context resume on i386 In-Reply-To: <20130717205656.GV5991@kib.kiev.ua> Message-ID: <20130718150806.J857@besplex.bde.org> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> <20130717205656.GV5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=XOoJF2RE c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=IpbkEbG0bHYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=T3l0V36KyEQA:10 a=K71uCMlgZFfCaxTWLx8A:9 a=CjuIK1q_8ugA:10 Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 05:34:12 -0000 On Wed, 17 Jul 2013, Konstantin Belousov wrote: > On Tue, Jul 16, 2013 at 06:54:57PM +1000, Bruce Evans wrote: >> ISTR disagreeing with jkim on using a special save area. > I believe the normal save area cannot be used there at all, since > the suspension is async and fpu.c could perform some operation on > the PCB-pointed save area while suspend IPI is received. If that happens, then suspension is broken anyway. Any npx operation on the pcb (or any other operation on the pcb) between savectx() and resumectx() makes the state saved by savectx() out of date. In normal kernel operations, the npx state is changed from volatile to non-volatile by pushing it to the pcb. This prevents context switches from changing it underneath you by doing the same push to the pcb. (The state is not really changed, but the place where it lives and pointers and flags that say where it lives are changed.) I think this works perfectly for suspend/resume too. It is less clear what happens for non-npx parts of the pcb. Hopefully there are no races for them (and the special save area is not needed) because there is no lazy context switching for them -- they live either in the CPU or the pcb, and are switched between the CPU and the pcu atomically on every context switch. Clearly context switches must not be allowed between suspend and resume, or the resume must be on the same thread as the suspend. Otherwise resume restores state for a wrong thread, which is a much larger bug than races and inconsistencies in accessing separate save areas for the same thread. > ... > Also, the comment before the %cr0 manipulations to set CR0_PG was > copied from amd64 version and is irrelevant there. I can't find this comment or any setting of CR0_PG in either swtch.s file. Bruce