Date: Thu, 18 Jul 2013 15:33:59 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-acpi@FreeBSD.org Subject: Re: Revisiting FPU context resume on i386 Message-ID: <20130718150806.J857@besplex.bde.org> In-Reply-To: <20130717205656.GV5991@kib.kiev.ua> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> <20130717205656.GV5991@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130718150806.J857>