From owner-freebsd-arch@FreeBSD.ORG Mon Dec 26 22:08:13 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ADEC106566B for ; Mon, 26 Dec 2011 22:08:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 09F9C8FC08 for ; Mon, 26 Dec 2011 22:08:12 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBQM7voj008492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2011 00:07:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBQM7uWi001825; Tue, 27 Dec 2011 00:07:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBQM7ugE001824; Tue, 27 Dec 2011 00:07:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Dec 2011 00:07:56 +0200 From: Kostik Belousov To: amd64@freebsd.org Message-ID: <20111226220756.GR50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YzFme3vxTykXnmM8" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: AVX 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: Mon, 26 Dec 2011 22:08:13 -0000 --YzFme3vxTykXnmM8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, The patch at http://people.freebsd.org/~kib/misc/avx.1.patch is the preliminary version, i.e. WIP, of the implementation of variable-sized extended FPU states, as defined by Intel SDM. The architecture (sometimes referred to as XSAVE) allows CPU to provide additional context state data and report the details of context save area layout to OS in the extendable form. AVX with it 256-bit YMM register file is the first application of the architecture. Due to extensibility and self-description of XSAVE area, by default kernel allows all CPU extensions, i.e. also possible future features of FPU. The tunable 'hw.xsave_allow_unknown' is provided, which disables CPU features not known to the kernel. The tunable 'hw.use_xsave' may be used to disable XSAVE support at all. The 'struct fpusave fpu_user_save' member was removed from amd64 pcb, the save area is chopped from the top of the thread kernel kernel stack (fpu_user_save was located there previously). I moved thread0 pcb set up after first stage of FPU initialization is done. Also, there is a silent change in fpu init code, now we explicitely clear XMM register file in the initial FPU state. At least on my SandyBridge, XMM init state is garbage, could be some vacuum tubes they stuff into chip were broken when machine crashed from 1 meter down. Since YMM file is part of the FPU state, it must be added to mcontext_t. Unfortunately, it is impossible to extend mcontext_t in-place and not break present ABI without duplicating all syscalls and libraries entries that use ucontext_t. The cause is that ucontext_t layout puts mcontext_t into the middle of the structure, frozing its size. The solution in the patch is to put extended save area outside the mcontext_t, and place a pointer to area in mcontext_t. Pointer validity is specified by _MC_HASFPXSTATE mcontext_t flag. Signal post provides the extended area on the signal stack frame automagically. If pointers to area are in context, setcontext(2) uses it. For getcontext(2), no easy solution exists. I tried to play with providing libc wrapper for getcontext(2) that hides mcontext_t size increase, but gave up due to ucontext_t embedding. Instead, getcontextx(3) API is implemented that allocates the needed memory. The patch defines ABI for both i386 and amd64 FreeBSD processes, but the implementation is provided for amd64 kernel only for both ABIs. I do not see any reason to run i386 kernel on machines capable of AVX. The fpu_kern KPI has to be changed to accomodate for variable size TODO items: - I think we are eligible for XSAVEOPT use, but did not looked into details yet; - benchmark the cost for context switches and signal handlers entry/sigreturn; - makecontextx(3) ?; - padlock(4) testing; - make i386 fpu_kern KPI changes; - implement (trivial) getcontextx(3) for other architectures. Patch in the present form only usable on amd64 machine for both amd64 and i386 userspace. --YzFme3vxTykXnmM8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk748DwACgkQC3+MBN1Mb4j0QQCfXTUIz73F08AmyLo0mppP0+1y VZMAoMLckeDmraBPb47HKhirrMxGJOiM =PzoA -----END PGP SIGNATURE----- --YzFme3vxTykXnmM8--