From owner-freebsd-arch Thu Jan 10 8:25:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5591D37B41A for ; Thu, 10 Jan 2002 08:24:51 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA23691; Thu, 10 Jan 2002 09:22:34 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AGMHe23293; Thu, 10 Jan 2002 09:22:17 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.49081.206713.580230@caddis.yogotech.com> Date: Thu, 10 Jan 2002 09:22:17 -0700 To: Dan Eischen Cc: Peter Wemm , Nate Williams , Daniel Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3D8C47.D3B11B87@vigrid.com> References: <20020110091018.0788A38CC@overcee.netplex.com.au> <3C3D8C47.D3B11B87@vigrid.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > FWIW, this is no longer the case. On all current CPUs, there are a whole > > stack more registers. The context save buffer is 512 bytes long. It isn't > > all used yet, but will be at some point in the future as long as you use > > the defined fxsave/fxrstor instructions. > > > > struct envxmm { > > u_int16_t en_cw; /* control word (16bits) */ > > u_int16_t en_sw; /* status word (16bits) */ > > u_int16_t en_tw; /* tag word (16bits) */ > > u_int16_t en_opcode; /* opcode last executed (11 bits ) */ > > u_int32_t en_fip; /* floating point instruction pointer */ > > u_int16_t en_fcs; /* floating code segment selector */ > > u_int16_t en_pad0; /* padding */ > > u_int32_t en_foo; /* floating operand offset */ > > u_int16_t en_fos; /* floating operand segment selector */ > > u_int16_t en_pad1; /* padding */ > > u_int32_t en_mxcsr; /* SSE sontorol/status register */ > > u_int32_t en_pad2; /* padding */ > > }; > > struct fpacc87 { > > u_char fp_bytes[10]; > > }; > > struct xmmacc { > > u_char xmm_bytes[16]; > > }; > > struct savexmm { > > struct envxmm sv_env; > > struct { > > struct fpacc87 fp_acc; > > u_char fp_pad[6]; /* padding */ > > } sv_fp[8]; > > struct xmmacc sv_xmm[8]; > > u_long sv_ex_sw; /* status word for last exception */ > > u_char sv_pad[220]; > > } __attribute__((aligned(16))); > > > > There are eight 10-byte registers, and eight 16-byte registers. > > > > union savefpu { > > struct save87 sv_87; > > struct savexmm sv_xmm; > > }; > > > > /* and this is what we save for userland state */ > > struct pcb { > > ... > > union savefpu pcb_save; > > }; > > > > When a userland application does a getcontext(), the kernel looks at > > fpcurthread to see if the calling process/thread/whatever has got its > > context stored in the pcb or in the live registers. There is no need to > > copy state to the FPU solely in order for the userland to save a copy. > > I think we determined that the only time we care about the FP state is > when sending a signal. Bruce stated this, but I'm not sure I agree since it's not obvious (to me anyway) that this always works when doing yield's and such which don't cause a signal to be sent. > In that case, the kernel should know how to get the FPU state and copy > it out to the context. If there are different FPU formats, there is a > flags word that can be set accordingly and the userland setcontext() > can be made to account for different floating point formats. See above. > Currently the kernel doesn't save the FPU state in the sigcontext, > but it should. Wouldn't this solve the problem? I believe so, given the comments stated on this thread. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message